Re: [PATCH net] netfilter: nf_nat_masquerade: recalculate TCP TS offset when port is randomized

On 7/8/2026 11:23 PM, Florian Westphal wrote:
> xietangxin <[email protected]> wrote:
>> 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.
> 
> I don't think the forwarding case is fixable.
> 
> Host S could be another NAT gateway, so it could be possible that
> the connections originate from different physical machines and
> timestamps differ due to different clocks, not per-connection
> randomisation.
> 
>> Since skb->sk is NULL on the forwarding gateway, my current approach of
>> updating tp->tsoffset in struct tcp_sock cannot be applied here.
> 
> Yes. I think the tp->tsoffset recalc is fine to handle local case.
> 
> For local case we do know that we're the end host and ts recalc is fine.
> 
>> 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?
> 
> If we have some guarantee that internal network isn't doing any
> snat at all, then yes, one could implement some TS adjustment
> scheme similar to seqadj extension we already have to deal with
> tcp sequence number adjustments.
> 
> We'd have to keep state and subtract the offset to get back the
> right tsecr again on reverse direction.
> 
> I'm not keen to have something like this, it would breaks PAWS
> as soon as the originating host is itself a nat gateway.
> 
> Is this really a problem to begin with?
Hi Florian,

Thanks for your precise analysis. I completely agree with you that
the forwarding case is theoretically unfixable due to the multi-tier NAT risks.

This is a real and severe problem for us, but the actual issue we encountered
is in the local case, not the forwarding case:

1.Laboratory Test Case Failure:
We noticed a severe HTTP performance regression in our automated Kubernetes testing,
where wrk was used to benchmark Pod client http performance. Through git bisect,
we successfully pinned the commit 165573e41f2f ("tcp: secure_seq: add back ports to TS offset").
The trigger was the default MASQUERADE --random-fully rule configured by kube-proxy on the k8s node.

2.Downstream Production Impact (AI Inference Cluster on Kubernetes):
Shortly after, one of our major downstream product teams reported a massive performance degradation.
After they upgraded their kernel to a version containing commit 165573e41f2f,
they suffered a 40% AI inference performance drop. They confirmed that simply
removing the random-fully flag instantly restored the performance back to normal.

Would it be acceptable to a V2 patch that targets the local case?

-- 
Best regards,
Tangxin Xie