IPv6 and Multi-WAN - Feature Request?

inferno480

So I have a scenario in which my primary WAN has a static /126 in which my ISP is routing me a /48.

I am running a DHCPv6 Server on my LAN interface for the /48 space; the interface IP of my LAN is the::1 address of that /48.

Everything works splendidly in a single WAN setup, however there's a major show-stopping issue as soon as I introduce Multi-WAN.

I found this great document that describes the caveats (which impact me), but I am curious if what I need is a feature request or if there is some script or workaround:

https://doc.pfsense.org/index.php/Multi-WAN_for_IPv6

The issue is, my WAN2 (backup connection) is a cable modem, that performs a DHCP request for its own v6 address but also gives me a /64 PD (I think I can request a /63 as well). The problem is, if I happen to have a fail-over to WAN2, my LAN interface/DHCP6 server is blissfully unaware of the failover and is still handing out addresses from the (now-unrouteable) /48 space. All of my machines with v6 addresses experience an outage, DNS won't resolve, etc.

There is a workaround described in the article that I linked above, for how to use NPt, but in the case of my WAN2 / cable modem connection, there is no telling what the /63 or /64 Prefix-Delegation addresses are that I am going to receive. Is there a way to somehow make this a variable in the NPt field where you define the v6 translations? That would be a god-send.

David_W

As you correctly surmise, NPt can be used to support IPv6 failover if you have multiple WAN connections but this currently requires static IPv6 addressing on all networks.

The "Track Interface" / DHCP-PD functionality in pfSense really needs some redesign and enhancement, as there are various issues with it as it stands. In particular, the current code does not deal well with a change of delegated prefixes. Adding support for failover would be a worthwhile part of this redesign.

There really is no reason for ISPs to use dynamic prefix allocations for IPv6 as the address space is large enough to give every account a static /48. I can understand those who argue a static /48 is wasteful for a home user, as they are unlikely to need more than the 256 /64s allowed in a /56. Unfortunately, many ISPs are still stuck in IPv4 like thinking when it comes to IPv6 and refuse to allocate a static /56 (or larger) to end users.

If you can't persuade the cable ISP to delegate a static /56, the best answer is to set up a tunnel to SixXS or Hurricane Electric over the cable connection, and get a static /48 routed over that tunnel. Hurricane Electric will work best if you have a dynamic IPv4 address on the cable modem, as pfSense has built in Dynamic DNS support for HE tunnel end points.

Once you have your tunnel set up and working, you can use NPt for IPv6 failover to the tunnel.

inferno480

Thanks so much for the suggestion of using HE.net – it worked like a charm on the PCs for basic IPv6 connectivity. However, I ended-up having to back-out from IPv6 completely. The three people in my house all have Samsung Galaxy S5 Android smartphones and they are NOT IPv6 friendly whatsoever. Apparently there is some bug pertaining to the hardware or firmware of the WiFi chipset in these phones and they do not work with IPv6 at all. They will not do DHCPv6, and no SLAAC or RA setting seemed to work with them. Oh well, I'll give IPv6 another go once we upgrade our phones in a few months (hopefully). But, I just wanted to say thanks for the suggestion, it worked great.

(Side note: I also found out the hard way that my WiFi AP currently has a bug where it falls back into Auto channel selection [and into crowded 2.4 GHz space, in my case] every time it gets reset or loses PoE power… good times!)

David_W

@inferno480:

Thanks so much for the suggestion of using HE.net – it worked like a charm on the PCs for basic IPv6 connectivity.

Great - that's one problem solved.

@inferno480:

However, I ended-up having to back-out from IPv6 completely. The three people in my house all have Samsung Galaxy S5 Android smartphones and they are NOT IPv6 friendly whatsoever. Apparently there is some bug pertaining to the hardware or firmware of the WiFi chipset in these phones and they do not work with IPv6 at all. They will not do DHCPv6, and no SLAAC or RA setting seemed to work with them.

Android does not support DHCPv6 and, despite many requests, the engineer responsible for this issue at Google seems implacably opposed to adding DHCPv6 support. You need to use SLAAC.

The SLAAC/RA problem has previously been discussed, and I posted a patch for pfSense 2.2.x.

To use that patch, install the System Patches package (if you haven't got it installed already) and create a new patch:

Press the Save button, then the option to 'Apply' should appear next to the patch, so press 'Apply'. Restart the radvd service using Status -> Services to bring the new value into operation. At that point, your S5 phones should work correctly with IPv6.

In pfSense 2.3, the RA default lifetime is configurable in the pfSense user interface.

@inferno480:

(Side note: I also found out the hard way that my WiFi AP currently has a bug where it falls back into Auto channel selection [and into crowded 2.4 GHz space, in my case] every time it gets reset or loses PoE power… good times!)

Device firmware often contains a shocking number of bugs. Product lifecycles are short and maintenance is often low priority, especially for discontinued or consumer grade devices.

Things are not always much better with expensive enterprise grade equipment. I've got an enterprise grade dual band access point here that doesn't work properly if the RADIUS server allocates a VLAN to a client when the AP is in autonomous (no controller) mode. My suspicion is that the bridging is not being configured correctly, as static allocation of SSIDs to different VLANs works correctly.

I really must get round to reporting that issue to the vendor, as there is a software support contract for the unit and it is a current product.

Inq

@David_W:

Android does not support DHCPv6 and, despite many requests, the engineer responsible for this issue at Google seems implacably opposed to adding DHCPv6 support. You need to use SLAAC.

If someone really needs DHCPV6 on android there is a nice client aviable on google play https://play.google.com/store/apps/details?id=org.daduke.realmar.dhcpv6client
It works fine on my Z1 compact (5.01 lolipop). Root required of course.