IPv6 IP Alias prevents Track Interface from working with DHCPv6 and RA
I'm attempting to have GUA and ULA addresses provisioned to clients on the LAN interface by using DHCPv6 to provide GUA addresses and Router Advertisements to provide both GUA + ULA routes so that clients generate addresses via SLAAC. This is to allow for resilient IPv6 connectivity since my ISP provides a /56 over DHCPv6, which requires me to use Track Interface. Under DHCPv6 Server & RA > VLAN5 > Router Advertisements, I've added fdc0:ffee:5::1/64 to RA Subnets and switched the Router Mode to Assisted. The IP Alias is set to fdc0:ffee:5::1/64 for the VLAN5 interface.
This setup works perfectly until I reboot the pfSense machine or reset the LAN interface. This causes the IP Alias / CARP address to appear as the primary interface route and the tracked interface to appear as a secondary route (only visible by running
netstat -nr). Both DHCPv6 and RA give out ULA routes only. I suppose this would be fine if the bug occurred with a static IPv6 prefix from an HE.net tunnel because one could add the static prefix to the RA Subnet tab. Unfortunately, I've seen my DHCPv6 prefix change with a modem reboot so that wouldn't work. I tested it with 6to4 and didn't encounter this problem, so it seems to vary based on the type of interface.
I've found the output of
ifconfig lagg0_vlan5 | grep inet6 to be directly correlated to the problem. Here's the output:
Before applying IP Alias to VLAN5
inet6 2600:8805:5::1 prefixlen 64 inet6 fe80::1:1%lagg0_vlan5 prefixlen 64 scopeid 0x9
After applying IP Alias to VLAN5
inet6 2600:8805:5::1 prefixlen 64 inet6 fe80::1:1%lagg0_vlan5 prefixlen 64 scopeid 0x9 inet6 fdc0:ffee:5::1 prefixlen 64
inet6 fdc0:ffee:5::1 prefixlen 64 inet6 2600:8805:5::1 prefixlen 64 inet6 fe80::1:1%lagg0_vlan5 prefixlen 64 scopeid 0x9
After VLAN5 and/or WAN reset
inet6 fdc0:ffee:5::1 prefixlen 64 inet6 fe80::1:1%lagg0_vlan5 prefixlen 64 scopeid 0x9 inet6 2600:8805:5::1 prefixlen 64
I don't know much about how BSD/pfSense decide which IPv6 route to pass onto radvd or which prefix to use for DHCPv6 clients but as a temporary workaround I'm using a script that runs
ifconfig lagg0_vlan5 | grep inet6 every minute. If the line containing
inet6 fdc0 occurs before the line containing
inet6 fe80 (ie. if it looks like the last two outputs above), then it executes
ifconfig lagg0_vlan5 inet6 fdc0:ffee:5::1 prefixlen 64 -alias && ifconfig lagg0_vlan5 inet6 fdc0:ffee:5::1 prefixlen 64 alias to force the ULA address/route to the bottom, which gets DHCPv6 and radvd working correctly so I think that the problem lies here somewhere.
Hopefully this helps.
#2 Updated by Michael Marley about 3 years ago
Another issue that seems to be related to this is that firewall rules using "LAN net" and similar are not obeyed if you have multiple subnets with the ULA Virtual IPs. The code that generates the firewall rules appears to only be using the primary IPv6 address, which is the public prefix from track6. It looks like the code needs to handle all the IPv6 addresses on the interface and not just the first one, both for DHCPv6/RA and for generating firewall rules.
#4 Updated by Doug Twitchell about 2 years ago
Fixing this would help with the problems discussed in this forum post: https://forum.pfsense.org/index.php?topic=126978.0
#6 Updated by Jupiter Vuorikoski 10 months ago
Did not realize that there was an issue as old as this when i first made my own tickets. This affects every version of pfsense until the very latest. The fix would be as simple as to not treat Virtual IPs as candidate addresses for actual configuration daemon and instead wait for tracked addressing to come up before writing radvd and dhcpd config.
This would NOT be difficult to implement and dismissing it as something to be addressed in the unforeseeable future is just shameful.
#8 Updated by Tony Fortes Ramos 10 months ago
Jim Pingle wrote:
If it is "simple" and "not difficult", we would happily accept a pull request to fix the issue.
Well, I really don't know how to cleanly fix this, but from what I have seen, three steps are needed to fix it:
- change the order of the IP's on the interfaces so the ULA is below the tracked IP
- update the radvd.conf file
- restart radvd
The first and last steps I can do with my ULA IP's hardcoded into a script. Sadly, I cannot figure out how to regenerate the radvd config file.
#9 Updated by Chris Linstruth 3 months ago
As far as I can tell there are too many assumptions placed on the order of the addresses on the interfaces.
There are two things in play that I see:
1. Generation of radvd.conf
2. Generation of pass "LAN interface" rules.
If the GUA from track interface is the first one listed in ifconfig, everything seems to work fine.
If the ULA address is listed first, everything pretty much breaks.
With a dynamic prefix delegation, even a relatively-stable one, standard practice is to use both ULA and GUA on inside interfaces as outlined in RFC7368 3.4.2.