Home / server / Questions / 1047463
In Process
Guss
Asked: 2020-12-25 06:35:49 +0800 CST

Segmenting IPv6 networks using dnsmasq?

  • 772

I have a bit of a complicated network setup(*) where a WAN router connects to the upstream provider and provides an "external LAN" (where actually I have some services) and another local router has its external leg on the "external LAN" and provides an "internal LAN" (where most nodes are connected and there's also a DMZ host). IPv4 Clients on the "internal LAN" are double NATed and it works well enough for my needs (also the DMZ setup works well with the internal router set as the "DMZ host" for the WAN router).

No the WAN router has been upgraded with an IPv6 connected and the "external LAN" is provided with a 56 bit network - lets call it 2001:db8:2:300::. Hosts on the "external LAN" can DHCPv6 and get a 64 bit network address assigned to them and it works.

I want to have the internal router - which is running dnsmasq for network management - to offer IPv6 to the internal clients. I have selected a valid 64 bit network inside the "external LAN" 56 bit network - lets call it 2001:db8:2:333:: and have set up the internal router's "internal LAN" leg with the ::1 of that network. I had then set up dnsmasq to offer DHCPv6 on the "internal LAN" using:

enable-ra
dhcp-range=::2, ::FFFF:FFFF, constructor:vlan4, ra-names, 64, 12h

(on the internal router, vlan2 is the "external LAN" and vlan4 is the the "internal LAN")

I can trace now connect an "internal LAN" client and get an IPv6 address and ping the internal router. When I ping anything outside of that - such as the WAN router's internal IPv6 gateway port - I don't get a reply. Pings and connections from the internal router itself work well. I can trace an ICMP packet on the internal router and see it going out of the correct interface, but no reply is received.

As far as I understand, the WAN router doesn't understand where to send replies to hosts in 2001:db8:2:333:: as it thinks they should be directly connected on its LAN, but they aren't actually there.

I think I should have the internal router send Router Advertisement for 2001:db8:2:333:: to the WAN router? I tried to get dnsmasq to do it by adding:

interface=vlan2
dhcp-range=2001:db8:2:300:1234:5678:abcd:100,2001:db8:2:300:1234:5678:abcd:400,ra-only,infinite

But that doesn't work because clearly I have no idea what I'm doing. ??

A network expert that I manage to get 30 seconds of attention from said that I need to have internal router be a DHCPv6 relay towards the WAN router, so that the WAN router can allocate addresses to the internal clients and know to route to them through the internal router - but I can't figure out how to get dnsmasq to do that, while keeping IPv4 DHCP running as it is, as dnsmasq man page says that you can't have dhcp-relay and dhcp-range on the same interface.

I would love to try any suggestion and/or be taught about IPv6 because while I'm pretty good at IPv4 networks, IPv6 is clearly a bit over my head.

*) This weird setup is mostly due to issues of trust and control of the WAN router, which are out of scope of this issue, so if your only suggestion is to change that setup - please don't.

local-area-network ipv6 dnsmasq

3 Answers

  1. The key here is letting the upstream DHCP server know that you will be handing those addresses to devices not directly attached to the WAN router.

    Configure your LAN router:

    1. to enable the PD flag on top of what its dhcpv6 client already does, and
    2. in dnsmasq, enable router announcements, constructor: automation, and proxy dns&ntp.

    If you do not care about which specific prefix is used, neither does dnsmasq:

    enable-ra
dhcp-range=::,constructor:wanside,1h
dhcp-option=option6:dns-server,::
dhcp-option=option6:ntp-server,::

    Really, that was it? Well..

    It worked for me, years ago, with a (literally) black box WAN, but the mechanism - while meant for such use case and mostly well defined - was and still is riddled with bugs in all involved software.

    I know nothing about DHCP relaying, this answer is about automatic prefix delegation.

    Internet
|
|     /----- directly attached machines
WAN router 
| v announces itself as router *AND* leases a /64 *AND* larger PD prefix
|       
| ^ requests its own /64 *AND* larger PD prefix *AND* a router address
my Router (and a firewall, but for once it did not interfere)
| v announces itself as router *AND* hands out /64s
|
| ^ request a /64 each *AND* a router address
internal boxes

    Delegation is the option where

    1. the WAN Router does not need to know individual addresses used by the internal LAN, and
    2. your internal LAN uses both link-local & globally routable addresses, and
    3. once setup, it reconfigures new addresses as needed, even with wiped / replaced WAN router.

    Details

    • You want the LAN Router to have both the address it gets that one via the more common DHCPv6 options already and additionally you want it to request a prefix the WAN box knows to be delegated to not-directly-attached boxed
    • No obvious way to tell dnsmasq "forward dns and ntp addresses as-is", but you probably were going to proxy it anyway, that is what dnsmasq does, right?
    • dnsmasq is picky about which address space to select when using constructor:, that is why no further configuration is necessary
    • dnsmasq is only announcing still-valid addresses in RA, thus the address dnsmasq announces as router to its downstream clients does not matter as long as the interfaces are separate on layer 2
    • I ran a separate dhclient that already supported the option back then (WIDE I believe), but but by now most clients, even systemd-networkd (albeit not via netplan) can be configured to do it and still request another directly leased prefix.
    • The IA_PD request can ask for a specific prefix size or even a specific prefix. Start without doing that, and only enable it after the simple case works for more consistent network addresses.
    • The WAN router completely forgot about the delegated prefix and associated routes as soon as the delegation expired. For extra fun, the dhcp client did not put the expiration from dhcp in the IP address expiration where it would have been obvious. You need to confirm that your dhcp client actually renews the lease including the delegated prefix - they do not necessarily expire at the same time.
    • 1

  2. As far as I understand, the WAN router doesn't understand where to send replies to hosts in 2001:db8:2:333:: as it thinks they should be directly connected on its LAN, but they aren't actually there.

    The first router has no idea that the network behind the second router exists or how to reach it.

    Routers learn routes in three ways:

    1. Directly connected networks
    2. Statically configured routes
    3. Dynamically through routing protocols

    Because the network on the other side of your second router is not directly connected to the first router, the first router will need to either have a static route configured that points to the second router for the network on the other side of the second router, or you will need to use a routing protocol between the two routers to exchange routing information.

    Statically configured routes do not scale, but may be fine for a small network that does not change often. Routing protocols are useful for larger networks, but are also fine for small networks if you do not want to be bothered to configure static routes, and they can be useful to prevent mistakes when configuring static routes.

    • 0

  3. I have a very similar setup where I have a WAN router, that manages a DMZ and a raspberry pi connected to it, running Raspbian (Debian port for the pi). The raspberry pi again manages two subnets, one being my home network and another, which is my guest network.

    The WAN router is a fritz box. It receives a fresh /56 prefix everyday early in the morning from my ISP. From that /56 prefix it uses a /64 prefix to manage the DMZ and it is configured to allow delegated smaller prefixes in the network.

    The raspberry pi requests such a prefix from the fritz box on eth0. As a result it gets a /62 prefix assigned, which is used for my home (eth1) and guest (eth2) networks.

    # cat /etc/network/interfaces.d/eth0
auto eth0
    allow-hotplug eth0
    iface eth0 inet dhcp
    iface eth0 inet6 dhcp
        accept_ra 2
        request_prefix 1
        autoconf 1

    The prefix is delegated to my home network on eth1 and guest network on eth2 with the script and steps described here: https://wiki.debian.org/IPv6PrefixDelegation (I modified the script to support two subnets for my home and guest networks, but the original does the trick for only one network).

    Once the prefix is delegated, the fritz box knows where to route the addresses of the /62 prefix to, since it knows which host requested it. And the pi knows how to handle it as well, as routes are set by assigning the /62 subnet, which is done by the prefix delegation script.

    Finally, I told dnsmasq to construct router advertisement from the eth1 interface (and from eth2 for the guest network, but I'll leave that out for simplicity reasions) like so:

    enable-ra
dhcp-range=tag:eth1,::,constructor:eth1,ra-names,ra-stateless,slaac,2h

    You can basically follow the instructions from the Debian wiki. It pretty much lines down the whole procedure. You can leave out the radvd configuration, since you configured dnsmasq to do the router advertisement. Adopt the instructions to your distro, if you do not use Debian. They should all work the same, more or less :-)

    Additionally, I had to set the life time of the ipv6 leases to only two hours in dnsmasq, as it announces the old prefixes in the morning for that time only and I noticed problems with my home and guest network clients otherwise, when the prefix changes.

    Sadly, you mentioned the wan router is out of your control. Unfortunately you probably have to configure the WAN router to allow prefix delegation in the network, if it is not already configured to do so.

    For the fritz box, they provided some documents for that: https://en.avm.de/service/fritzbox/fritzbox-7490/knowledge-base/publication/show/1239_Setting-up-an-IPv6-subnet-in-the-FRITZ-Box/

    Hope this helps. Good luck!

    • 0