Multiple IPv6 bugs / quirks in pfSense

RMO

Hi everyone.

I'm going to preface this post by stating that I actually have been able to get basic IPv6 connectivity working on pfSense. This includes both IPv6 with ULAs through DHCPv6 and NAT66, and IPv6 using IPv6 Prefix Delegation and SLAAC giving out the PD'd GUAs. So for basic operation, not much issue, but I have found several things that start popping up when trying to do more "advanced" IPv6 stuff on pfSense, and one quirk or bug even in basic operation.

This is all from 2.4.5-RELEASE-p1

"default allow LAN IPv6 to any" rule does not work right after boot when using IPv6 PD
Quite simply, you boot, you get an IPv6 PD and give it out through SLAAC on your LAN interface, machines get an IP but aren't able to connect to the internet over IPv6. If you check the firewall logs, you'll see the traffic gets dropped due to the default drop all rule.

Workaround : disable and enable any firewall rule to force a reload of the rules. After that, connectivity works.

My assumption for the root cause: the "LAN net" source does not get updated correctly when the PD gets assigned, since it does take a while to get the PD and assign it to all the needed interfaced. Because of this, the traffic from the PDd IPs is not recognised and dropped. Reloading the rules forced a reload of the "LAN net" source and thus makes it work.

assigning a virtual IPv6 IP to an interface that has IPv6 PD track interface enabled makes the Virtual IP the primary IP after reboot
Situation: you have a LAN interface that gets an IP through IPv6 PD. You add a virtual IP, for example a ULA, to that same interface. You can confirm through ifconfig that the interface has both IPs and prefixes. You reboot pfSense. After reboot, the Virtual IP is now the primary IP, the PD'd IP does not show up in the interface, but you can still see it through ifconfig. However, this causes a ton of issues within pfSense.

Problems this causes
-radvd gives out a prefix based on the virtual IP rather than the PD'd IP
-similar to nr 1 : the PDd ip range does not get added to "LAN net" and therefore connectivity through the PD'd prefix does not work (the routes do get added to pfSense though, so pfSense is at least partially aware)

My assumption for the root cause: the Virtual IP is a static IP that gets loaded immediately onto the interface at bootup, after which other components use it. The PD'd IP comes later once the PD has been received, but has not triggers to incorporate it into other parts of pfSense.

radvd only gives out the prefix of the "first" IPv6 address of an interface
Bit of an extension of nr2
Situation: When multiple prefixes are available on an interface (like a PD'd GUA and a locally defined ULA), only the first one gets sent out through the RA.

Now, I could live with this if it was consistently the PD'd IP that got sent out, and I could add my own ULA as additional prefix in the GUI if I wanted to (since I might want to deal out the ULA through DHCPv6 instead of SLAAC), but then the RA would have to consistently be able to send out the PD'd prefix. Currently it is unnpredictable, or predictably wrong.

The DHCPv6 relay always uses the "first" IPv6 address of an interface
Situation: you have multiple IPv6 addresses defined on an interface, such as a PD'd GUA and a locally defined ULA. You deal out the GUA via SLAAC, but want to use DHCPv6 for the ULAs and therefore enable the DHCPv6 relay

Problem: the relay will put the "first" address as relaying address, which can be the GUA, or like I have mentioned in the above issues, could be the ULA, it all depends. When it is the GUA however, the DHCPv6 server will refuse to serve the subnet since of course it does not know that prefix and has no IPs for it.

The common thread among all these issues is that pfSense seems to not consistently take into account use cases where multiple IPv6 addresses and/or prefixes are known to an interface, which is however a standard use case within IPv6, especially when mixing GUAs and ULAs.

I know some of you may ask "why do you want to mix GUAs and ULAs". Simple: because I can't predict what my GUA prefixes will be since it is given through PD and thus can change, but when I want to dual stack internally I need predictability through either static addressing or DHCPv6 with reservations (for Active Directory and internal Dynamic DNS for example), and ULAs give that. This is also not an issue for IPv6, the rules for address selection means that for example a client will use its GUA to talk to resources on the internet but use its ULA to talk to local resources that also have a ULA.
So my end desired state is giving all my machines a GUA through SLAAC and IPv6 PD, and a ULA through DHCPv6. I can do either of those individually with pfSense, but when I try to do both at once, I run into the above issues.

So questions are: anyone else seeing this? What's my way forward, logging bug reports? I'm not too familiar with the redmine system that Netgate seems to use. I can pretty consitently reproduce the above issues, so there's that at least.

JKnott

@RMO

Why are you using NAT66? No need for NAT, when you have gazillons of addresses.

On the WAN pages, make sure Do not allow PD/Address release is selected. Get the basic config working first, before trying anything fancy, so you have some idea as to where the problem comes from.

RMO

@JKnott
I was using NAT66 before IPv6 PD was properly working on my modem.
Now that it is, I want to move to PD + SLAAC for public data communication, but with still ULAs for internal communication to my servers.
And that's where the above issues arose.

As I mentioned, I do have the basic config working, PD+SLAAC by itself works fine apart from issue nr1.

So just to be clear: my TO-BE situation is no NAT66, public IPs for all my systems through PD+SLAAC and ULAs for all my systems through DHCPv6.

JKnott

@RMO

When you set up ULA, you will also have to specify the GUA prefix in Subnets on the RA config page. This is one area where pfSense needs some improvement, as it shouldn't forget the GUA prefix when ULA is added.

RMO

@JKnott
yeah already tested that. Technically works, but requires manual configuration and requires re-configuration when the prefix changes.

also, because of issue nr1 the GUA prefix gets dropped so need manual firewall rules as well. Oddly enough the "reload firewall rules" trick didn't work for me in that instance.

so a lot of stuff is work-around-able, but it's not pretty and not "how it should function".

also I run into the issue in that scenario where the ULA prefix is then distributed via SLAAC, which I don't want, since I want to use DHCP for ULA.

viktor_g

@RMO issues created:
https://redmine.pfsense.org/issues/10712
https://redmine.pfsense.org/issues/10713
https://redmine.pfsense.org/issues/10714
https://redmine.pfsense.org/issues/10715

you can register on the redmine.pfsense.org and leave any extra comments