Project

General

Profile

Actions

Bug #8276

closed

Virtual IPs considered primary when using interface tracking for ipv6

Added by Jupiter Vuorikoski about 6 years ago. Updated over 5 years ago.

Status:
Duplicate
Priority:
Normal
Assignee:
Category:
IPv6 Router Advertisements (radvd/rtsold)
Target version:
-
Start date:
01/13/2018
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.4.2_1
Affected Architecture:

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.

Actions #1

Updated by Jim Thompson about 6 years ago

  • Assignee set to Jim Pingle
Actions #2

Updated by Jupiter Vuorikoski about 6 years ago

This affects the dhcpv6 server as well. Logic needs to be applied to never consider a VIP a primary address.

Actions #3

Updated by Jim Pingle about 6 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.

Actions #4

Updated by Jupiter Vuorikoski about 6 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.

Actions #5

Updated by Ulf Merbold over 5 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

Actions #6

Updated by Jim Pingle over 5 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.

Actions

Also available in: Atom PDF