On Thu, Jun 12, 2025 at 08:13:02PM +0000, Klaus Frank wrote: > On Thu, Jun 12, 2025 at 09:45:00PM +0200, Phil Sutter wrote: > > On Thu, Jun 12, 2025 at 08:19:53PM +0200, Antonio Ojea wrote: > > > On Thu, 12 Jun 2025 at 15:56, Phil Sutter <phil@xxxxxx> 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@xxxxxx> 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). > > Well technically all that needs to be done is NAT66 instead of NAT44 > within that hack and that limitation vanishes. I don't comprehend: I have to use an IPv4 transfer net because I need to set a source address in the generated IPv4 header. The destination IPv4 address is extracted from the IPv6 destination address. Simple example: IPv6-only internal: fec0::/64 v6mapped: cafe::/96 external IPv4: 1.2.3.4 internal transfer IPv4: 10.64.64.0/24 Client sends: IPv6(fec0::1, cafe::8.8.8.8) nat64 in fwd: IPv4(10.64.64.1, 8.8.8.8) nat in postrouting: IPv4(1.2.3.4, 8.8.8.8) Google replies: IPv4(8.8.8.8, 1.2.3.4) nat in prerouting: IPv4(8.8.8.8, 10.64.64.1) nat64 in fwd: IPv6(cafe::8.8.8.8, fec0::1) > > 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. > > If nat64 functionality was added within conntrac itself then it would be > easy to reuse the l7 helpers. If it was anywhere else the l7 helpers > within conntrack would have to be re-implemented as conntrack wouldn't > know the mappings and therefor it probably would be quite hard to do the > rewrites. > Also in regards to FTP not just L7 headers but also payload needs to be > edited on the fly. As it often uses differnt commands for IPv4 and IPv6 > (even though the IPv6 ones also support IPv4) and it embeds the IPs as > strings. > > EPRT<space><d><net-prt><d><net-addr><d><tcp-port><d> > > where "net-prt" is either 1 for IPv4 or 2 for IPv6. and net-addr is the > string representation. > However a client may send the "PORT" command instead... > Also RFC2428 may be helpful in this context. > > I think if it was possible to get the nat64 into conntrack it should > also be possible to take care of this more easily as with external > "hacks". I agree it would probably be the cleanest solution. > Also in regards to the above code it looks like currently only tcp and > udp are supported. All other traffic appears to just dropped at the > moment instead of just passed through. Is there a particular reason for > this? I guess tcp and udp are simply sufficient in k8s. Cheers, Phil
