Re: Status of native NAT64/NAT46 in Netfilter?

[Phil Sutter <phil@nwl.cc>]

On Thu, Jun 12, 2025 at 08:19:53PM +0200, Antonio Ojea wrote:
> On Thu, 12 Jun 2025 at 15:56, Phil Sutter <phil@nwl.cc> wrote:
> >
> > Hi,
> >
> > On Thu, Jun 12, 2025 at 03:34:08PM +0200, Antonio Ojea wrote:
> > > On Thu, 12 Jun 2025 at 11:57, Phil Sutter <phil@nwl.cc> wrote:
> > > > On Sun, Jun 08, 2025 at 08:37:10PM +0000, Klaus Frank wrote:
> > > > > I've been looking through the mailling list archives and couldn't find a clear anser.
> > > > > So I wanted to ask here what the status of native NAT64/NAT46 support in netfilter is?
> 
> > > we ended doing some "smart hack" , well, really a combination of them
> > > to provide a nat64 alternative for kubernetes
> > > https://github.com/kubernetes-sigs/nat64:
> > > - a virtual dummy interface to "attract" the nat64 traffic with the
> > > well known prefix
> > > - ebpf tc filters to do the family conversion using static nat for
> > > simplicity on the dummy interface
> > > - and reusing nftables masquerading to avoid to reimplement conntrack
> >
> > Oh, interesting! Would you benefit from a native implementation in
> > nftables?
> 
> Indeed we'll benefit a lot, see what we have to do :)
> 
> > > you can play with it using namespaces (without kubernetes), see
> > > https://github.com/kubernetes-sigs/nat64/blob/main/tests/integration/e2e.bats
> > > for kind of selftest environment
> >
> > Refusing to look at the code: You didn't take care of the typical NAT
> > helper users like FTP or SIP, did you?
> 
> The current approach does static NAT64 first, switching the IPv6 ips
> to IPv4 and adapting the IPv4 packet, the "real nat" is done by
> nftables on the ipv4 family after that, so ... it may work?

That was my approach as well: The incoming IPv6 packet was translated to
IPv4 with an rfc1918 source address linked to the IPv6 source, then
MASQUERADE would translate to the external IP.

In reverse direction, iptables would use the right IPv6 destination
address from given rfc1918 destination address.

The above is a hack which limits the number of IPv6 clients to the size
of that IPv4 transfer net. Fixing it properly would probably require
conntrack integration, not sure if going that route is feasible (note
that I have no clue about conntrack internals).

The actual issue though with protocols like FTP is that they embed IP
addresses in their headers. Therefore it is not sufficient to swap the
l3 header and recalculate the TCP checksum, you end up manipulating l7
headers to keep things going. At least there's prior work in conntrack
helpers, not sure if that code could be reused or not.

Cheers, Phil