Bug #6678
closedVirtual IPv6 IP (IP Alias) on a DHCPv6-PD tracked interface causes inconsistencies
0%
Description
2.3.2-RELEASE (amd64)
WAN interface gets a IPv6 /60 prefix delegation from my ISP. (example: 2001:1:2:30/60) My LAN interface is configured to track that IPv6 with a prefix ID of 1 (so comes up with 2001:1:2:31:a:b:c:d) DHCPv6 Server is configured to hand out a range of ::1000 to ::2000. RA is enabled (assisted mode.)
Given that configuration, a device attaching to the LAN interface will be DHCPv6 assigned an address similar to 2001:1:2:31::1000 and/or use stateless to give itself a 2001:1:2:31::/128.
If I then add a virtual IPv6 IP (IP Alias) to the LAN interface with a ULA address (such as fd01:19fc:be04:1:/64), save the virtual IP, nothing in radvd.conf or dhcpv6.conf changes. Then I go into the interfaces->LAN, re-save the LAN interface (and apply) it causes radvd.conf and dhcpv6.conf to be updated. However, now it uses the ULA prefix instead of the tracked IPv6 prefix.
Being that radvd.conf and dhcpv6.conf is only providing a SINGLE prefix (and not multiple prefixes - one for the global and one for the ULA), it would be more desirable for the global to be advertised (as it's the only one routable outside the site - in theory.)
So, two issues here:
1. Virtual IP additions either shouldn't cause changes to the DHCPv6/RA configurations or should at least give the option of which address to use. (In other words, favor the properly configured IPv6 over virtual ones.)
2. If #1 should always change to use the virtual IP and not the globally tracked one, then it should either do so immediately on saving, or remind the user to edit/save/apply the interface for the changes to be reflected. (Otherwise, it's inconsistent.)
I'm not sure the best category for this ticket. CARP? DHCP6?
Updated by Gary Dezern over 8 years ago
In addition, this messes up the snort default pass list, adding the VIP instead of the actual interface IP.
Updated by Anonymous over 8 years ago
This looks like it might be a duplicate of https://redmine.pfsense.org/issues/5999.
Updated by Gary Dezern over 8 years ago
agreed on it being a dupe. Not sure how I missed 5999 when I searched initially.