Zone transfer over VPN

[Greg Choules]

Hi Michael.
Have you tried without the "allow-transfer" statements at all? I find it
usually works best to start simple, get it working, then apply security bit
by bit.
Do you have logs from all servers? What are they telling you specifically
about what is the issue?
Lastly, get packet captures of port 53. Evidence is always handy to see
what is actually going on, rather than guessing what you *think* should be
going on.

Cheers, Greg

On Tue, 6 Sept 2022 at 23:16, Michael De Roover <isc at nixmagic.com> wrote:

> Hello everyone,
>
> I have currently 2 internal networks under my control, both of which have
> BIND
> name servers in them. The "main" network uses the 192.168.10.0/24 subnet,
> while the "satellite" network uses the 192.168.20.0/24 subnet. Following
> this,
> I will refer to these as main and satellite. You may consider the
> satellite
> network sort of like a road warrior setup, though both are fully-fledged
> networks with hosts in them.
>
> The main network has a set of two gateways with IP addresses
> 192.168.10.51,
> and 192.168.10.52. They perform VRRP to each other, with floating IP
> 192.168.10.9. Both of them make a VPN connection to two VPS's using
> WireGuard.
>
> The VPS's have IP ranges 10.8.2.0/24 and 10.8.3.0/24 respectively. Pretty
> much
> all traffic that's relevant here (AXFR/IXFR on TCP 53) goes through the
> former.
>
> The satellite network does the same thing, it also connects to the VPS's
> but
> does not perform VRRP with another node. The gateway on the satellite
> network
> uses IP address 192.168.20.1.
>
> The name servers on these networks are 192.168.10.4, 192.168.10.5 and
> 192.168.10.6 on the main network, and 192.168.20.3 on the satellite
> network.
>
> This is running on BIND 9.16.25 for Alpine on the main network, and BIND
> 9.11.5-P4-5.1+deb10u7-Debian for Debian on the satellite network. All of
> them
> are running in LXC with bridged networking.
>
> Now I would like to get both of these networks to share their local zones.
> So
> in the name servers' configs I would initially declare an ACL for this and
> add
> that to the zone entries, on the main network. This worked fine for those,
> being in the same subnet. But once I tried to do the same on the satellite
> network, BIND on the main network would see the zone transfer as coming
> from
> 192.168.10.51 or 192.168.10.52 -- instead of coming from 192.168.20.3 --
> and
> refuse it. The same is true the other way around, where the name server on
> the
> satellite network sees zone transfers from the main network as coming from
> 192.168.20.1 instead.
>
> In other words, only the first hop (or the last, depending on how you look
> at
> it) is being considered, with zone transfers seemingly being expected to
> occur
> from within the same subnet. Surely I'm not the only one who dealt with
> this?
> If anything, I consider myself still a newbie. Is it possible to get BIND
> to
> consider the original source of the zone transfer instead?
>
> For now I have added an "external" ACL to these networks, and made the
> respective local zones authorized to transfer from this ACL, which has the
> gateways of their local networks in there. However, this means that
> anything
> on the main network can transfer from the satellite network, and anything
> from
> the satellite network can transfer from the main network. After all, the
> name
> servers have no way to tell where it's really coming from. While
> everything on
> these networks is owned or otherwise controlled to a reasonable extent by
> me,
> I don't like this. In my book, this is a security issue. I think I need a
> better solution for this.
>
> Configuration-wise, this would be a snippet from ns1.lan on the main
> network
> with the relevant bits.
>
> acl external {
>        admin;
>        192.168.10.9;
>        192.168.10.51;
>        192.168.10.52;
> };
> ; ...
> zone "lan" {
>        type master;
>        file "/etc/bind/zones/fwd.lan.db";
>        allow-transfer { internal; external; };
> };
> zone "10.168.192.in-addr.arpa" {
>        type master;
>        file "/etc/bind/zones/rev.lan.db";
>        allow-transfer { internal; external; };
> };
>
> The satellite network's name server has a similar configuration to this,
> but
> the other way around.
>
> I have skimmed over these articles so far, but couldn't find anything
> relevant
> in them.
> - https://kb.isc.org/docs/aa-00726
> - https://www.zytrax.com/books/dns/ch7/xfer.html
>
> Thank you so much for taking your time to read this, and thanks in advance
> for
> any insights.
>
> --
> Met vriendelijke groet / Best regards,
> Michael De Roover
>
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220906/0a9a859a/attachment.htm>