BUG in IPv6: Adding ULA Virtual IP breakes RA at LAN interface
-
Setup: ppoe WAN dual Stack with rolling GUA, LAN is set for "Track IP", an addional ULA IP is added for LAN Interface, DHCP6 off and RA set to assisted
GUA prefix /56, LAN does propagage the GUA with /64 in RAAs long u didnt reconnect, everthing is working fine.
After the daily reconnect a new GUA prefix is send by provider.ifconfig at LAN interface shows the correct IPv6 IP's, (ULA, changed GUA, and the LL), but now in different order.
Now does the underlying logic the "magic", but since the order of the IP's changed, the RA now propagades the ULA prefix and not the GUA prefix.
before reconnect, the radvd.conf shows the correct GUA, after reconnect the conf is setup for the ULA prefix, which is nuts ^^
NDP list shows the changed GUA at LAN port, but its totally ignored by any configuration pfsense does after the reconnectSince IPv6 is made for multiple IP this behavior is counterproductive at all and breaks the GUA propagation into the inner network.
-
I'm sorry, but your post is so confusing, I'm having a problem understanding it. For example, what is a "rolling GUA"? I know what GUA refers to. Also pfSense does support GUA and ULA on the same network. I've done it here. There were some issues however, which I discussed here a while ago.
-
Yeah, sry for the tech slang which was growing over the years.
rolling = non static and unpredictable GUA from ISP
And sure, as i stated, ifconfig for lan shows ALL ipv6 adresses!
BUT: when u get a new GUA from ur ISP the ordering of these adresses in pfsense changes.And this has an reproducable result:The propagated IPv6 into the inner network will change from GUA to the VIP ULA. ->Fail1
And since the radvd config is created from this result, the RA now advertise the VIP network, which makes the function useless then. ->Fail2
The only workaround is to delete the vip adress, save and create it again, then the correct and WANTED! GUA prefix will propagated again in the router advertisement.
And reproduceable is this wrong behavior too.
Everytime an ppoe reconnect happens u get an new GUA from ISP. This results in a new GUA for the LAN port, then the ordering of the Ipv6 Ip's changes and whoop u'll see now the ULA VIP as main IPv6 IP and in the radvd config the ULA prefix as advertised network!And this is clearly a bug if an different ordering of IP adresses has different results for the configuration.
And yes, i've read many many posts, but an solution about an buggy behavior wasnt stated.
Edit: Sorry for my "bad" english, if u wish we could further discuss in perfect german :) But hey, joking, english is ok for me, u just have to be a bit more calm about some of my crazy sentences please.
Edit2(missed something): I think the main problem is how pfsense is using the underlying configurations of an interface.
If i go for the interface informations over the management site, i only get two IPv6 adresses shown...GUA or ULA depends on which is first in the list and the link local adress.
ULA+LL adress or GUA+LL adress....but not ALL adresses this interface has configured.(Behavior Management Website)
If i use the console, and do an ifconfig "interface", then ALL configured interface adresses are shown.
And normally this should be the base for the RADVD configuration. -->since this is automated by pfsense i didnt know where to go in for changing this. -
I have exactly the same problem.
My setup is slightly different.
My WAN is set to DHCP and DHCP6. My assigned prefix doesn't normally change that often, but from time to time it does. (For example after a power outage that take a while to solve; or after network maintenance by our ISP)Anyhow, I too have track interface on my LAN (and VLAN) interfaces, and had added Virtual IPs to those interfaces as well. Those Virtual IPs were ULA addresses, where the intention was that I could always reach the firewall by its virtual IP.
In my case I do not have to wait for a ppoe reconnect or a DHCP renewal on the WAN interface, it is enough that I reboot my pfSense to reproduce it.
When that happens the GUA address on the LAN or VLAN interface is replaced by the Virtual IP and the RA stops 'distributing' the GUA adresses to the clients.
I too have no solution for that, so I have removed the Virtual IPs to get the GUA anouncements working again.