Undesirable behavior? IP Alias VIP takes over interface's IPv6 in radvd, etc

garyd9

My "LAN" interface is configured to "track" the WAN assigned prefix. So, if my ISP gives me 2001:1:1:10/60, my LAN interface uses the configured prefix ID of 1, and gives itself an IP of 2001:1:1:11::1, and radvd/dhcpv6 handle everything so that ipv6 addresses in the 2001:1:1:1/64 "subnet" are handed out.

However, if I create a Virtual IP (IP Alias) for that same LAN interface, and assign the adapter a ULA IPv6 (fd01:19fc:be04:1::1/64 in my case), suddenly radvd and dhcpv6 on the LAN interface stop using the tracked IPV6 and instead start using the virtual IP. So, instead of 2001:1:1:11/64 addresses showing up on devices attached to that interface, I see fd01:19fc:be04:1::/64 addresses showing up. (The 2001:.. address is never advertised as the router, etc, so clients have no idea that they can or should use an address in that network.)

Obviously, ULA's aren't (or at least shouldn't be) routable outside a site local scope. (Funny, though, that comcast lets them go through… I had a successful traceroute to ipv6.google.com from a ULA.)

I think the problem is that there's no way on the DHCPv6 and RA service pages in the webUI to tell the services to ignore the ULA and use the tracked IPv6.

I can actually understand a use-case where a person might want the ULA's to be assigned to the clients and NOT the global addresses (if, for example, they wanted to do a IPv6 NAT?)

However, I'd think IF the interface has a choice between configuring dhcpv6/radvd for ULA's or global addresses, and if there's no way to specify which should be used (or no way to configure that BOTH should be used), that the global address should be chosen by default.

...Is there a way for me to work around the described behavior to get what I'm after? Is this a bug, or just something I find undesirable?

Thanks
Gary

garyd9

…and of course - after fighting with this for 2 hours... now that I posted about it, it's not repeating. (I'm getting the primary global ipv6 in radvd.conf and dhcpdv6.conf for the interface and no mention whatsoever of the ULA in the files.) Maybe if I reboot the router it'll go nutty on me again?

Perhaps there's some particular pattern of saving things and apply things in a specific order I had done earlier (or didn't do this most recent time.) Or, perhaps pfSense will just decide to change things later on for me. ;)

Regardless, if it "sometimes works" one way and sometimes works another - I'd think that this would go from "maybe a bug or maybe undesirable" to "bug due to inconsistency."

EDIT: Ah, got it to happen again. ;) I went back to the interface and saved/applied.. and now radvd is advertising the ULA prefix instead of the global one:


interface igb1 {
        AdvSendAdvert on;
        MinRtrAdvInterval 5;
        MaxRtrAdvInterval 20;
        AdvLinkMTU 1500;
        AdvDefaultPreference medium;
        AdvManagedFlag on;
        AdvOtherConfigFlag on;
        prefix fd01:19fc:be04:1::/64 {
                DeprecatePrefix on;
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr on;
                AdvValidLifetime 86400;
                AdvPreferredLifetime 14400;
        };
        route ::/0 {
                RemoveRoute on;
        };

It seems that once this happens, the only way to "fix" it is to delete the virtual IP. Oh, and after you delete the virtual IP, you STILL have to go back to the interface and save/apply it again in order to get radvd.conf updated.

Created https://redmine.pfsense.org/issues/6678

garyd9

Is there any way to work around this issue? Perhaps some script that I can modify which gets called any time dhcpv6.conf and radvd.conf is written?