Native NAT64 support

[bestboy]

Hi,

I'm currently experimenting with IPv6-only networks. I might soon get a DS-Lite connection and consider finally getting rid of IPv4 (except for some niches) and run an IPv6-preferred network.
For testing I have NAT64 set up with the Tayga plugin and DNS64 deployed via Unbound. This setup works ok. The fact that many clients on Android, iOS and recent Windows support 464XLAT by now helps to mitigate issues with IPv4 literals that can not be addressed by DNS64. DHCP option 108 is already available and PREF64 support is on the way (I think radvd 2.20 supports it already, only UI support is missing). All things considered, I believe NAT64 could be a viable IPv4 transitioning solution. There is really only one single issue with my tests: IPSec

Why is IPSec important? Well, other than the fact that most corporate VPN solutions use IPSec, the main reason IMHO is VOWIFI aka Wifi Calling. VOWIFI allows handheld devices to extend the mobile network via a WIFI network. This is achieved by establishing an IPSec connection to an Evolved Packet Data Gateway (ePDG) of the mobile provider via the internet. This essentially brings mobile services to where no mobile reception is. I'm sure most of you know Wifi Calling. IMHO a killer feature not to be missed.
The IPSec mode used by the VPN connection to the ePDG is tunnel mode with the ESP protocol and UDP encapsulation (NAT-T). Unfortunately, the ePDGs seem to be using IPv4 exclusively (see https://www.netify.ai/resources/mobile-gateways). I do not know why there is still no support for IPv6, even though mobile providers feel the pain of IPv4 address space running out. I also do not know of any plans to change that in the near future. So one can assume Wifi Calling with IPv6 will require NAT64 for the time being.

Now, the good thing is, NAT64 in general should be able to support IPSec with the ESP protocol (unlike IPSec with the AH protocol). However, NAT64 via Tayga does not. In my tests I was not able to use IPSec and in extension Wifi Calling. As far as I can tell Tayga simply does not have support for protocol 50 (ESP) - only 1 (ICMP), 6 (TCP) and 17 (UDP). I believe support for rewriting ESP headers could just be added, but it's not there for now.

TL;DR: NAT64 via Tayga is incomplete.

Which brings me to the actual question: What is the current state of "native" NAT64 support on OpnSense? Are there any plans to support NAT64 besides the Tayga plugin? I could not find anything in the roadmap about it.
I'd assume using Jool is out of the question being a Linux kernel module.
FreeBSDs own IPFW has support for NAT64. The original PF on OpenBSD has support for NAT64, too. The FreeBSD port of PF however does not have NAT64 support AFAIK, because it was forked before NAT64 support was added.
PFSense seems to have gotten native support for NAT64 recently, but I do not know how it is implemented there.

[Monviech (Cedrik)]

Wouldn't it still be better to run dual stack for a few more years until IPv6 penetration reached the last isolated IPv4-only services? Dual stack is well documented and just works for most setups without much oddities.

Im just curious why running IPv6 only with a translation to IPv4 is even worth it. I don't negate the hobbyist aspect of it though.

Though if the tools do not offer what you need, why not wait for a while longer?

[Patrick M. Hausen]

Im just curious why running IPv6 only with a translation to IPv4 is even worth it.

We do it in our hosting environment to preserve IPv4 addresses. Standard product is a FreeBSD jail with IPv6 only, NAT64 and DNS64 so the customer can access e.g. Github. Inbound SNI proxy for HTTP and HTTPS, one proxy per physical machine. We also provide a dual stack SSH jumphost.

NAT64 is done with IPFW.

IPv4 addresses cost real money, nowadays. If you want dual stack for your jail, we charge 5€ per month.

[patient0]

The FreeBSD port of PF however does not have NAT64 support AFAIK, because it was forked before NAT64 support was added.
PFSense seems to have gotten native support for NAT64 recently, but I do not know how it is implemented there.

Native NAT64 - by the keyword 'af-to' - was introduced with FreeBSD 15[1].

The question came up before on the forum but I can't find it right now. The gist is: OPNsense will adopt FreeBSD 15.1, timeline Mid to End 2026, if I remember correctly (or Dec 2026 - Mid 2027?).

Btw, apalrd has taken over Tayga[2] and is pushing it further but I'm not sure if his/their effort is Linux only. In the video I think is only Linux mentioned.

[1]https://man.freebsd.org/cgi/man.cgi?query=pf.conf&manpath=FreeBSD+15.0-RELEASE
[2]https://github.com/apalrd/tayga
[3]https://www.youtube.com/watch?v=WlQH8KubgiA

[Maurice]

I've experimented with WiFi Calling over NAT64 in the past and never got it to work. If anyone had success with this (with any NAT64), I'd be interested. But I'd say it's up to the MNOs to add IPv6 support to their ePDGs.

The new pf 'af-to' feature in FreeBSD 15 indeed makes native NAT64 in OPNsense realistic in the near future. From a quick look, it seems that's what pfSense uses, too (by using FreeBSD prerelease code?). But I'm not very confident this solves the WiFi Calling use case (although I'd be happy to be proven wrong).

@Monviech For general purpose networks, directly switching from Dual Stack to IPv6-only without NAT64 seems unrealistic anytime soon. Some IPv4-only services will be around for many, many years. So IPv6-only with NAT64 is a sensible intermediate step. Among other reasons, it eliminates the management and troubleshooting overhead of Dual Stack while maintaining compatibility with legacy IP.
If you're more conservative, you can go Dual Stack with IPv6-only preferred first, but this requires NAT64, too.

@patient0 apalrd has mentioned being an OPNsense user, but I'm not sure whether he uses the OPNsense Tayga plugin or Tayga on a dedicated Linux system.

Cheers
Maurice