lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABhP=tbUuJKOq6gusxyfsP4H6b4WrajR_A1=7eFXxfbLg+4Q1w@mail.gmail.com>
Date: Thu, 12 Jun 2025 20:19:53 +0200
From: Antonio Ojea <antonio.ojea.garcia@...il.com>
To: Phil Sutter <phil@....cc>, Antonio Ojea <antonio.ojea.garcia@...il.com>, 
	Klaus Frank <vger.kernel.org@...nk.fyi>, netfilter-devel@...r.kernel.org, 
	Pablo Neira Ayuso <pablo@...filter.org>, Florian Westphal <fw@...len.de>, Lukas Wunner <lukas@...ner.de>, 
	netfilter@...r.kernel.org, Maciej Żenczykowski <zenczykowski@...il.com>, 
	netdev@...r.kernel.org
Subject: Re: Status of native NAT64/NAT46 in Netfilter?

On Thu, 12 Jun 2025 at 15:56, Phil Sutter <phil@....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@....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?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ