25.03-BETA NAT64 / PREF64 Success and feedback

bschapendonk

First of all, thank you for implementing NAT64 and PREF64 .

I have tested these, and a quick test showed that they work fine.

Created a NAT64 rule with the standard PREF64 prefix on LAN
Configured the PREF64 prefix under Router Advertisements
Disabled KEA DHCPv4 on LAN

Tested this on Android (Airplane mode, only WIFI and verified that it only had IPv6 conectivity), which with all of the above, it only has IPv6 connectivity (no IPv4). And I can, still access sites like github/twitter, which are IPv4 only (using Androids CLAT stack)

Now, it would be really nice if pfSense would implement DHCP option 108 for KEA DHCPv4 (this turns off the IPv4 stack on client devices, if they have IPv6 connectivity).
See:

Or custom DHCP options, but I guess that would be more work then just adding a option to turn option 108 on.

Sidenote, ICMP doesn't seem to work , but this might be normal, I'm not sure (I have a floating allow ICMPv4 and ICMPv6 form any to any rule). Anyway:

I can ping 9.9.9.9, but I can't ping [64:ff9b::9.9.9.9] which I would have expected.
I can both open https://9.9.9.9/ and https://[64:ff9b::9.9.9.9]/ in a browser and both give me a "404 not found", the same result as expected.

Questions:

Does NAT64 block the usage of RFC1918 addresses, otherwise NAT64 could be used to bypass the firewall (this might also depend on the Address Family Translation source setting, is Automatic safe?). I need to test this somehow.

ps. feel free to move this topicus to the Plus 25.03 Develoment Snapshots categaory (which nobody can create a topic in atm.)

keyser

@bschapendonk This is a really interesting new feature for pfSense. Client side CLAT’s are all the rage right now in the IPv6 world.
And justly so…. It will likely be what really does bring IPv6 out of its stalemate and onto the actual IPv4 succesion path that was intended.
Now we just need MS to deliver a properly working CLAT as well….

We just need IPv6 only clients to become “common” using CLAT to reach the odd IPv4 site to really put pressure on IPv6 migration worldwide.

dstacey147

@bschapendonk If I have a delegated /56 prefix and multiple subnets, do I need a different NAT64 Prefix for each subnet interface? i.e. 64:ff9b::/96 on LAN and 64:ff9c::/96 on LAN2?

kprovost

@bschapendonk said in 25.03-BETA NAT64 / PREF64 Success and feedback:

I can ping 9.9.9.9, but I can't ping [64:ff9b::9.9.9.9] which I would have expected.

That's weird:

% ping6 64:ff9b::9.9.9.9
PING6(56=40+8+8 bytes) 2a02:1811:2410:bf00:9d1e:68:3be:876f --> 64:ff9b::909:909
16 bytes from 64:ff9b::909:909, icmp_seq=0 hlim=57 time=19.520 ms
16 bytes from 64:ff9b::909:909, icmp_seq=1 hlim=57 time=19.501 ms

Perhaps there's a rule issue. I'd start by tcpdump-ing on the WAN interface to see if an IPv4 echo request makes it out or not.
And if it doesn't repeat the tcpdump on the LAN interface to make sure the icmp6 echo request is making it to pfsense.

bschapendonk

@keyser Afaik, Microsoft has plans, they annoucced (Windows 11 Plans to Expand CLAT Support) last year, but it has been radio silence since then. So we have to be patient I guess, like how Windows 11 24H2 magically (nothing anywhere announced) fixed RDDNS and you don't need a DHCPv6 server anymore to get a IPv6 DNS server.

@dstacey147 I think (I haven't readup on / tested this) that you use 64:ff9b::/96 everywere since NAT64 happens on the interface (hence isn't routed) So using 64:ff9b::/96 on LAN and LAN(x) should not matter.

@kprovost Good to know that it works. I'll figure it out eventually.

bschapendonk

Using the patch from Kea DHCP Custom Options Support (IPv4 and IPv6)
, and adding the following to Services -> DHCP Server -> Custom Options

{
    "option-data": {
        "lan": [
            {
                "name": "v6-only-preferred",
                "data": "3600"
            }
        ]
    }
}

Looks like this makes option 108 work. My Samsung S24 is now ipv6 only and uses CLAT (192.0.0.5 address) At a first glance everything (the usual ipv4 only holdovers like x/github/twitch etc...) ~~"just works"~~, broke Wifi calling (could be my mobile provider, or maybe related to my ping issue). Back to dual-stack for the work week.

dstacey147

@bschapendonk said in 25.03-BETA NAT64 / PREF64 Success and feedback:

@dstacey147 I think (I haven't readup on / tested this) that you use 64:ff9b::/96 everywere since NAT64 happens on the interface (hence isn't routed) So using 64:ff9b::/96 on LAN and LAN(x) should not matter.

Thanks, makes sense. I was asking because I had briefly glanced at something that I thought mentioned a possible conflict, but now I can't find it and everything I've looked at today only ever mentions the one prefix so I likely misread something.

patient0

@bschapendonk I have now set that up on VM with pfSense 25.03-BETA and KEA.

Two interfaces, LAN with DHCPv4, DHCPv6 disabled and RADVD set to unmanaged. The second interface TEST has DHCPv4 and DHCPv6 enabled and RADVD set to assisted.

Both works with fine Linux clients, one without DHCPv4 client enabled connecting to LAN and SLAAC for IPv6. The other DHCPv4 client and DHCPv6/SLAAC enabled connecting to TEST.

The PREF64 is set to the default 64:ff9b::/96.

Is there a way to see the PREF64 states? Running pftop and setting the filter to icmp crashes pftop. Not always but often and with a core dump.
Am I right in that I should see a IPv4 ICMP to the destination from the IPv4 WAN address (I do see that) and another from the local IPv6 network gateway to the IPv6 address of the client?

kprovost

@patient0 I assume you mean nat64 states when you say "PREF64 states"?

Those look something like this in the states overview:
all tcp <WAN_IP4>:61202 (<WAN_IP6>[61202]) -> <DEST_IP4>:5223 (64:ff9b::<IP4>[5223]) ESTABLISHED:ESTABLISHED

patient0

@kprovost thanks a lot, I will check that out.

fireodo

@patient0 said in 25.03-BETA NAT64 / PREF64 Success and feedback:

Running pftop and setting the filter to icmp crashes pftop.

Hi,

btw. here in pfsense 2.7.2 it crashes too:

pid 87545 (pftop), jid 0, uid 0: exited on signal 10

patient0

@fireodo is the 2.7.2 running on a Proxmox VM too?

patient0

@kprovost I did check it and I'm a bit confused about the difference if I check the states in the GUI or on the command line.

I have to preface the IPv6 on WAN is not set up to be able to connect out. WAN has a static IPv6 ULA set (for the moment), IPv4 can connect to the internet.

WAN: 10.101.102.40, fdaa:b2b4:d8b2:1000::40 (vtnet0)
LAN: fdaa:b2b4:d8b2:1021::1/64
Client : fdaa:b2b4:d8b2:1021:be24:11ff:fefb:cd2e/64 (SLAAC)

To test I wget start.duckduckgo.com (duckduckgo.com is still all IPv4 only, NAT64 of that host is ending in b19c)

on the client : $ wget -O - https://start.duckduckgo.com
and check the states in the shell on pfSense 25.03-BETA:

$ pfctl -s states | fgrep b19c
vtnet0 tcp 10.101.102.40:46466 (fdaa:b2b4:d8b2:1021:be24:11ff:fefb:cd2e[46466]) -> 40.114.177.156:443 (64:ff9b::2872:b19c[443]) FIN_WAIT_2:FIN_WAIT_2

That does make sense for me but then in the GUI the columns seem a bit mixed up
Screenshot 2025-02-17 at 10.13.48.png

bschapendonk

I somehow got my ping working.

This weekend I changed up some firewall rules.
Basically, I had 2 floating rules that allowed any ICMPv4 and ICMPv6 from any to any. I removed those and added two rules on my WAN (LAN has a allow all rule any why).

Any how it works now and I don't know what I changed to make it work

Next up, figuring out why WiFi calling stop workon Android.

~~I think WiFI calling uses IPSec, and IPSec ESP/AH protol might not be supported by NAT64~~
It's my mobile provider, seems WiFi calling only works using IPv4 (and then not using NAT64, CGNAT works, I think this is due to IPSec being used to secure WiFi calling and NAT64 doesn't work for IPSec ESP/AH traffic I believe)

fireodo

@patient0 said in 25.03-BETA NAT64 / PREF64 Success and feedback:

is the 2.7.2 running on a Proxmox VM too?

No - bare metal (see signature)