On 7/8/2026 11:23 PM, Florian Westphal wrote:

xietangxin [off-list ref] wrote:

quoted

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.

quoted

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.

quoted

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