Hi, Currently, when a conntrack entry is initialized, the tuple for the reply direction (nf_conn->tuplehash[IP_CT_DIR_REPLY]) is set to the tuple in the original direction inverted (see https://elixir.bootlin.com/linux/v6.1.6/source/net/netfilter/nf_conntrack_core.c#L1728). Further, if stateful NAT is subsequently done for the connection, the tuple is updated accordingly (https://elixir.bootlin.com/linux/v6.1.6/source/net/netfilter/nf_nat_core.c#L611). I propose to instead set the tuple when the connection is confirmed. And at that point, set it to the current address of the packet inverted. This address seems to be the most likely address that reply packets will have. How can the result be different from what we get with the current method? The packet may have been modified between when the conntrack entry was initialized and when it was confirmed. For example: * By using netfilter mangling features, for example as in https://wiki.nftables.org/wiki-nftables/index.php/Performing_Network_Address_Translation_(NAT) under stateless NAT. * By changing the address of the packet as part of routing, see http://linux-ip.net/html/nat-stateless.html (feature may not be available anymore). In my concrete case, I want to make a stateless 1:1 NAT using one of those features. And I need to do the NAT *after* the packet has been routed. And I want to use conntrack for stateless firewall and fastpath with flow tables. Would such a behavior be an improvement? Best Christian
