Bug #5999

IPv6 IP Alias prevents Track Interface from working with DHCPv6 and RA

Added by Abuzer Rafey about 3 years ago. Updated 3 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Affected Version:
Affected Architecture:


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 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

After reboot

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.


#1 Updated by Chris Buechler about 3 years ago

  • Category set to Interfaces
  • Status changed from New to Confirmed
  • Affected Version changed from 2.3 to All

find_interface_ipv6 returns the first IP on the interface in that case, which might not be the intended one in that situation.

#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.

#3 Updated by Michael Marley over 2 years ago

Any update on this? I would really like to be able to use ULA and GUA IPv6 addresses at the same time on my network, but this issue prevents me from doing so by making the GUA stop working whenever the router is rebooted.

#4 Updated by Doug Twitchell about 2 years ago

Fixing this would help with the problems discussed in this forum post:

#5 Updated by Jim Pingle 10 months ago

See also: #8276

#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.

#7 Updated by Jim Pingle 10 months ago

If it is "simple" and "not difficult", we would happily accept a pull request to fix the issue.

#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:

  1. change the order of the IP's on the interfaces so the ULA is below the tracked IP
  2. update the radvd.conf file
  3. 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.

Also available in: Atom PDF