Virtual IPs considered primary when using interface tracking for ipv6
On boot, if you have VIPs configured on an interface that uses interface tracking for its primary IP, the primary ipv6 prefix will not be added to radvd configuration at all and instead a VIP prefix is announced on the prefix. This causes loss of connectivity when having ULA IP Alias configured on an interface that uses interface tracking for its addressing.
Expected behavior: the VIP should never be configured or even considered to be advertised through radvd unless explicitly added to the subnets to be announced in the RA configuration. This could be added at the same time with functionality described in ticket #8262 with a "Primary interface prefix" as a dynamic object existing as default entry in the subnets field.
#4 Updated by Jupiter Vuorikoski 9 months ago
The problem of pfsense considering a VIP over the actual tracked interface IPv6 and never switching is still an issue that should be addressed. This is not something for some "long term design thought".
Behavior is not undefined when you want secondary addresses which prefixes are not announced in the RA packets on an interface. Only the primary address should ever be considered for radvd if there are no other prefixes configured to be announced. The behavior is the exact same as when one would have multiple ipv4 subnets on an interface (however invalid that design is), except in the case of IPv6 RAs exist instead of only one subnet being available to be served via DHCP in the ipv4 world.
Please dont bury this to be a footnote for future and fix the behavior instead. It will most likely only require some new variable to separate the primary address from secondaries.
Dear Jim Pingle, maybe u take a look into the RFC's of IPv6 and see that these specific type of setup is absolutely normal for IPv6.
Multiple IP, multiple routes, multiple routers and gateways. Rocket science to read and understand, really?
And btw this is the normal setup u need for any rolling IPv6 system most ISP's do!
Sad that u have to steady login to the firewall to delete the virtual ULA IP and setup again to fix that bug till next reconnect.
And "behavior undefined" as u stated is in RFC written down exactly WHERE? And how is this statement to see in context of the "virtual IP" function in pfsense?`
BTW bug still exists in 2.4.3, and this is a HUGE bug!
Note: RADVD grabs after every reconnect the "wrong" ULA adress and brings down the GUA advertisement this way. Brings the RA into an useless state