Transparent Proxy DNAT: Why the Return Route Matters
Understand why DNAT can deliver a request to a separate proxy while the reply bypasses the gateway and breaks the connection.
A redirected SYN can arrive at Squid while the client still times out. In a DNAT setup, the return packet must reach the gateway that owns the translation state too.
Consider this hypothetical LAN:
client 192.168.40.25 → gateway 192.168.40.1
DNAT → proxy 192.168.40.10
proxy 192.168.40.10 → client 192.168.40.25 directlyThe client originally connected to a website address. After DNAT, the proxy sees the client's source and may use its local subnet route to reply directly. That reply misses the gateway's reverse translation and can reach the client from the proxy address instead of the expected website address. The gateway cannot repair packets it never receives.
| Approach | Consequence |
|---|---|
| Route the proxy's replies through the translating gateway | The incoming proxy connection can retain the client's source address |
| Apply appropriate source translation too | The proxy replies to the gateway as its peer, but now sees that translated source rather than the original client |
Do not remove SNAT for nicer logs without verifying the return route. Applying it broadly also changes source ACLs and attribution; accept that consequence as part of the design.
A trusted HTTP hop can convey client metadata in a forwarding header, but NAT does not create that header or turn it into a TCP peer identity. Preserving a source on the connection into Squid also does not preserve it on Squid's separate website connection.
Finally, the interception design still needs to provide Squid's required destination information. Symmetric return routing solves this timeout mechanism, not the whole transparent-proxy configuration.