On 7/1/2026 10:17 PM, Florian Westphal wrote:

xietangxin [off-list ref] wrote:

quoted

Shifting the helper down to nf_nat_l4proto_unique_tuple() as you suggested
encounters a structural roadblock. we don't have access to the skb there.
Adding skb to all intermediate callers (like nf_nat_setup_info, get_unique_tuple)
would severely pollute the core NAT APIs.

Right, propagating the skb is too much code churn.

quoted

would it be acceptable to place this logic in nf_nat_inet_fn() before do_nat?

 963 do_nat:
             ..here

This is hit for every packet, not just the first one after
nf_nat_setup_info().  I suggest a slightly earlier spot in the
same function.

 936                                 ret = e->hooks[i].hook(e->hooks[i].priv, skb,
 937                                                        state);
 938                                 if (ret != NF_ACCEPT)
 939                                         return ret;
 940                                 if (nf_nat_initialized(ct, maniptype))
 941                                         goto do_nat;
 942                         }
 943 null_bind:
 944                         ret = nf_nat_alloc_null_binding(ct, state->hook);
 945                         if (ret != NF_ACCEPT)
 946                                 return ret;

 .... Here.

 947                 } else {

This spot runs only for new connections, right after a nf_nat_setup_info() call.

Hi Florian,

Thanks for your guidance. I’ve successfully fix the helper location
as you suggested, and it works fine for local traffic.

However, I realized that I had completely overlooked the forwarding scenario
(where SNAT acts as a middlebox gateway, e.g. Host A -> Gateway B -> Server C).
In this gateway scenario, when random-fully is enabled, the test results show
a massive performance degradation: the QPS drops from ~19000 down to ~10000.

Since skb->sk is NULL on the forwarding gateway, my current approach of
updating tp->tsoffset in struct tcp_sock cannot be applied here.
To be honest, I am currently stuck on how to handle this forwarding scenario
within the netfilter architecture without adding redundant overhead to the fast path.

Could you please give some advice on how the community would prefer to resolve this?
For instance, should we look into extending the Conntrack NAT extension to
track and adjust the TCP timestamps?

Any suggestions would be highly appreciated!

-- 
Best regards,
Tangxin Xie