Stateless NAT in nftables with maps for performance

Stateless NAT in nftables with maps for performance

[Juan Carlos Lazcano]

Hi netfilter community!
I'm trying to orchestrate the generation and maintenance of thousands of dnat & snat rules in a stateless configuration within the prerouting and forward hooks with chain types of filter, and unfortunately am hitting a big performance barrier as a result.  Its fine with a few thousand, but once we get into the tens of thousands of rules, things start slowing down linearly, which is why we would like to switch to maps.  However, I cannot figure out 1) if maps are supported in filter chains within prerouting/forward hooks and 2) if it supports the syntax for stateless nat?

For example:

table ip mytable {
	map dnat_map {
		type ipv4_addr : ipv4_addr
	}
	chain dnat {
		type filter hook prerouting priority raw; policy accept;
	}
}

I normally generate stateless dnat's via:

$ nft add rule ip mytable dnat ip daddr 100.101.84.137 counter ip daddr set 10.11.1.32 notrack comment "comment 1"


But, lets say I want to try to replace this rule with a map.  If i populate my map with a a key pair like:

$ nft add element ip mytable dnat_map { 100.101.84.137 : 10.11.33.32 }

How can I represent my original rule using a map?

I've tried:

$ sudo nft add rule ip mytable dnat ip daddr @dnat_map ip daddr set @dnat_map
Error: unknown raw payload base
add rule ip inode dns-dnat ip daddr @dnat_map ip daddr set @dnat_map
                                                           ^^^^^^^^^

and a few other variations, but I cannot figure out if this is even supported.

Any feedback would be great, I'm running nftables v1.1.5 (Commodore Bullmoose #6) & kernel 6.8.0-79-generic x86_64 on ubuntu 24.04

Thanks!

Re: Stateless NAT in nftables with maps for performance

[Florian Westphal]

Juan Carlos Lazcano <juan@placidnetworks.com> wrote:
> Hi netfilter community!
> I'm trying to orchestrate the generation and maintenance of thousands of dnat & snat rules in a stateless configuration within the prerouting and forward hooks with chain types of filter, and unfortunately am hitting a big performance barrier as a result.  Its fine with a few thousand, but once we get into the tens of thousands of rules, things start slowing down linearly, which is why we would like to switch to maps.  However, I cannot figure out 1) if maps are supported in filter chains within prerouting/forward hooks and 2) if it supports the syntax for stateless nat?
> 
> For example:
> 
> table ip mytable {
> 	map dnat_map {
> 		type ipv4_addr : ipv4_addr
> 	}
> 	chain dnat {
> 		type filter hook prerouting priority raw; policy accept;
> 	}
> }
> 
> I normally generate stateless dnat's via:
> 
> $ nft add rule ip mytable dnat ip daddr 100.101.84.137 counter ip daddr set 10.11.1.32 notrack comment "comment 1"
> 
> But, lets say I want to try to replace this rule with a map.  If i populate my map with a a key pair like:
> 
> $ nft add element ip mytable dnat_map { 100.101.84.137 : 10.11.33.32 }
> 
> How can I represent my original rule using a map?

ip daddr set ip daddr map @dnat_map
~~~~~~~~     #######
   |           \ The key to query the map for
   |
   \ What you want replaced

This rule is:
  [ payload load 4b @ network header + 16 => reg 1 ] # loads the key (second ip daddr).
  [ lookup reg 1 set dnat_map dreg 1 0x0 ]           # queries map
  [ payload write reg 1 => 4b @ network header + 16 csum_type 1 csum_off 10 csum_flags 0x1 ]
  # Then places the result of the map at the location (first ip daddr).

Re: Stateless NAT in nftables with maps for performance

[Florian Westphal]

Florian Westphal <fw@strlen.de> wrote:
> ip daddr set ip daddr map @dnat_map

Forgot the usual disclaimer: this breaks icmp(v6).

There is a reason for existence of stateful nat after all.

Re: Stateless NAT in nftables with maps for performance

[Juan Carlos Lazcano]

You all are amazing.  Thank you for all that you do!

My echo/reply base icmp functionality for v4 is working atleast at a cursory glance, without further testing I'm not sure what other parts of icmp are not working with this approach.

> On 09/12/2025 8:23 AM  Florian Westphal <fw@strlen.de> wrote:
> 
>  
> Florian Westphal <fw@strlen.de> wrote:
> > ip daddr set ip daddr map @dnat_map
> 
> Forgot the usual disclaimer: this breaks icmp(v6).
> 
> There is a reason for existence of stateful nat after all.

Re: Stateless NAT in nftables with maps for performance

[Florian Westphal]

Juan Carlos Lazcano <juan@placidnetworks.com> wrote:
> My echo/reply base icmp functionality for v4 is working atleast at a cursory glance, without further testing I'm not sure what other parts of icmp are not working with this approach.

Internal addresses leak via icmp dst unreach, redirects etc. which contain copies of
the (rewritten or original) addresses.
That in turn breaks path mtu discovery for instance:

Server may see internal address reflected in embedded header.
Client can receive error for source address it doesn't have.

NAT engine also rewrites embedded headers, see e.g. nf_nat_ipv4_fn()
in net/netfilter/nf_nat_proto.c and nf_nat_icmp_reply_translation() to
avoid this.

Re: Stateless NAT in nftables with maps for performance

[Pablo Neira Ayuso]

On Fri, Sep 12, 2025 at 03:37:36PM +0200, Florian Westphal wrote:
> Juan Carlos Lazcano <juan@placidnetworks.com> wrote:
> > My echo/reply base icmp functionality for v4 is working atleast at a cursory glance, without further testing I'm not sure what other parts of icmp are not working with this approach.
> 
> Internal addresses leak via icmp dst unreach, redirects etc. which contain copies of
> the (rewritten or original) addresses.
> That in turn breaks path mtu discovery for instance:
> 
> Server may see internal address reflected in embedded header.
> Client can receive error for source address it doesn't have.
> 
> NAT engine also rewrites embedded headers, see e.g. nf_nat_ipv4_fn()
> in net/netfilter/nf_nat_proto.c and nf_nat_icmp_reply_translation() to
> avoid this.

I think this can be fixed by extending userspace to mangle the icmp
payload, I would like to reach this at some point.