25.03-BETA NAT64 / PREF64 Success and feedback

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)