Bug #10713
closed
assigning a virtual IPv6 IP to an interface that has IPv6 PD track interface enabled makes the Virtual IP the primary IP after reboot
0%
Description
https://forum.netgate.com/topic/154856/multiple-ipv6-bugs-quirks-in-pfsense:
Situation: you have a LAN interface that gets an IP through IPv6 PD. You add a virtual IP, for example a ULA, to that same interface. You can confirm through ifconfig that the interface has both IPs and prefixes. You reboot pfSense. After reboot, the Virtual IP is now the primary IP, the PD'd IP does not show up in the interface, but you can still see it through ifconfig. However, this causes a ton of issues within pfSense.
Problems this causes
-radvd gives out a prefix based on the virtual IP rather than the PD'd IP
-similar to nr 1 : the PDd ip range does not get added to "LAN net" and therefore connectivity through the PD'd prefix does not work (the routes do get added to pfSense though, so pfSense is at least partially aware)
My assumption for the root cause: the Virtual IP is a static IP that gets loaded immediately onto the interface at bootup, after which other components use it. The PD'd IP comes later once the PD has been received, but has not triggers to incorporate it into other parts of pfSense.
Updated by Robby Moeyaert almost 4 years ago
I should add, the reason why I was using a Virtual IP here is that this is currently the only way of assigning multiple IPv6 addresses to an interface.
Ideally, you should be able to do this from the Interface GUI, where instead of just one option for the IPv6 address, you can add multiple entries, so that you can for example configure one entry as one being "track interface" and one as being "static IPv6", or just any of the available combinations.
Updated by Louis B almost 4 years ago
I do not understand this remark. Muliple address are only relevant (I think) if there are related to corresponding applications on the host. If so you need static iP's defined on the host itself. That is at least the way I have it working (IPV6). Of course this kind of remarks belong on the forum, but I could not resist to react :) Perhaps you could explain in the forum.
Updated by Robby Moeyaert almost 4 years ago
The "corresponding application" here would be the DHCPv6 relay that forwards to a DHCPv6 server that gives out ULAs, while pfSense gives out GUAs that were received through IPv6 PD. The relay needs to set its relaying IP to the correct subnet for the DHCPv6 server to answer, and that requires an IP within that range.
See also
https://redmine.pfsense.org/issues/10715
Most of the issues I have reported in that forum thread are related to that specific use case : having GUAs through IPv6 PD (which then also give temporary addresses for internet-facing communication), and ULAs through DHCPv6 which are used for internal communication, and whose AAAA & PTR records are then registered in the local DNS for internal use.
There's even an additional "issue" with the fact that pfSense (and OPNsense too for that matter) apply the same flags to all advertised prefixes. I need to set the A flag to have the IPv6 PD'd GUA working via SLAAC, but this then also enables the A flag on the ULA prefix that I need to announce to ensure clients know their on link prefix, which doesn't need it since I use DHCPv6 for assigning addresses on that prefix.
radvd supports setting the flags individually through its config file, but pfSense doesn't allow super granular config through the GUI and instead works with "presets" for the flags for all advertisements on an interface.
Updated by Viktor Gurov over 3 years ago
- Status changed from New to Duplicate
Viktor Gurov wrote:
https://forum.netgate.com/topic/154856/multiple-ipv6-bugs-quirks-in-pfsense:
Situation: you have a LAN interface that gets an IP through IPv6 PD. You add a virtual IP, for example a ULA, to that same interface. You can confirm through ifconfig that the interface has both IPs and prefixes. You reboot pfSense. After reboot, the Virtual IP is now the primary IP, the PD'd IP does not show up in the interface, but you can still see it through ifconfig. However, this causes a ton of issues within pfSense.
Duplicate of #5999