Dual WAN IPv6 with Failover on SG-1100
-
So I am trying to get a residential Dual WAN (failover) configuration working with IPv6 VPN subnets and messy residential dynamic DHCP address reservations.
WAN 1: (Failover) DSL PPPoE
WAN 2: CableI got IPv6 working on each of them, separately as single WAN configurations, using DHCPv6 on the WAN and track interface on the LAN.
Now I'm trying to move to a Dual WAN configuration.
If I understand correctly from the forums, the way to do this is to serve ULAs to the LAN via DHCPv6 and use NPt to do a 1:1 conversion to GUAs on the WAN.
ISP 1 has allocated me a permanent /56, and ISP 2 says that their /56 address should very rarely change.
So I'm trying to set-up ULA subnets being served by DHCPv6 on the LAN (which worked fairly well) and DHCPv6 on the WAN (as opposed to static), because I think I'll need to still reserve the address range on ISP 2, using the DUID, even though I make the assumption that the address range I'll get is always the same.
So, while it's all working successfully in a Single WAN configuration (i.e. pfsense is using DHCPv6 to provide IPv6 addresses to different VPN subnets and IPv6 traffic is routed successfully to the internet), but the WAN doesn't appear to reserve the /56 address via DHCPv6 if I'm not using Track Interface on the LAN.
Again, traffic is being successfully routed through the NPt, but the WAN link doesn't have any reserved IPv6 addresses, so I assume it's only working because the network still has a valid lease on the DHCPv6 server because it was previously negotiated?
I haven't gotten to testing NPt failover yet, which is hopefully the next step... but would love any feedback on my approach.
Edit: One bizarre new issue... after I converted the network from a normal IPv6 tracked interface to a ULA LAN with NPt, the network appears to suddenly prefer IPv4 over IPv6 (http://ds.testmyipv6.com/) when communicating using a dual stack. This wasn't a problem before NPt was put in place.
Any pointers for that issue appreciated as well.
-
Instead of implementing ULA inside and using NPT on both WANs I would consider keeping everything "normal" for the WAN2 connection and setting NPT on WAN1 to NPT from the WAN2 /56 to the WAN1 /56. That way you have no NPT in the path unless it's failed over. It should also only require that one setting.
I seem to recall an issue where the PD would not be asked for if there was not an interface that was set to track. I do not know if that was ever corrected. If that is still the case you might need to have a "dummy" interface set that tracks from that WAN (like a VLAN interface that goes nowhere) to kick dhcp6c into requesting the PD. I would verify that the static /56 isn't just routed to you anyway without it. Or if the ISP can just set it that way if not.
-
Instead of implementing ULA inside and using NPT on both WANs I would consider keeping everything "normal" for the WAN2 connection and setting NPT on WAN1 to NPT from the WAN2 /56 to the WAN1 /56. That way you have no NPT in the path unless it's failed over. It should also only require that one setting.
This would definitely solve the problems I'd been having. I only used the ULAs because it wasn't clear to me that the firewall subnet rules would work as cleanly in that scenario and because I saw this:
dlasher Jun 15, 2018, 3:32 PM - ULA + NPt seems to be about the only (mostly) reliable way to get Multi-WAN IPv6 working, with appropriate caveats.
But I'll give it a shot and report back.
I seem to recall an issue where the PD would not be asked for if there was not an interface that was set to track. I do not know if that was ever corrected. If that is still the case you might need to have a "dummy" interface set that tracks from that WAN (like a VLAN interface that goes nowhere) to kick dhcp6c into requesting the PD. I would verify that the static /56 isn't just routed to you anyway without it. Or if the ISP can just set it that way if not.
So funnily enough, I'd guessed that this was the problem and tried exactly that solution, a dummy tracked VLAN. It seemed as though that wasn't enough and that I needed some kind of traffic or client, since the WAN interface still didn't make the request and end up with an IPv6 address, but I'll test it more thoroughly.
If the previous suggestion works with a tracked interface, it'll solve this problem as well.
-
All of the PD and tracked interface settings happen in the dhcp6c client itself. It does everything. All it needs to be is set up and run.
Whenever you change an inside interface tracking setting you have to edit/save the WAN that is being tracked (or wait for a renewal) to get the changes applied because that re-runs the dhcp6c client on that interface.
