Bug #8276
closed
Virtual IPs considered primary when using interface tracking for ipv6
0%
Description
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.
Updated by
Updated by Jupiter Vuorikoski almost 7 years ago
This affects the dhcpv6 server as well. Logic needs to be applied to never consider a VIP a primary address.
Updated by Jim Pingle almost 7 years ago
- Target version deleted (
2.4.3)
I'm not sure we've ever officially endorsed that type of setup. The behavior is at best undefined. It's going to need more long-term design thought on how to handle that situation.
Updated by Jupiter Vuorikoski almost 7 years 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.
Updated by Ulf Merbold over 6 years ago
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
Updated by Jim Pingle over 6 years ago
- Status changed from New to Duplicate
Insulting people is not going to convince them you are right.
The behavior is undefined on pfSense, not in IPv6.
This is a duplicate of #5999 anyhow - closing this in favor of that other ticket.