[tproxy] Fwd: Tproxy changes for performing dual NAT
KOVACS Krisztian
hidden at sch.bme.hu
Tue Oct 30 11:40:36 CET 2007
Hi,
On k, okt 30, 2007 at 02:59:51 +0530, Arun S wrote:
> > That seems ok and it works in the first scenario. This is what I
> > tested with netcat patched to use IP_TRANSPARENT socket option. But I
> > didn't use SNAT because IP_TRANSPARENT lets the program bind to any
> > IP address when it connects to any other server (this would be the
> > server-side connection of the squid if the binding to foreign address
> > is necessary).
>
> That is fine. Since IP_TRANSPARENT lets the program to bind to any IP
> address, the application can be made to use any IP address as the
> source.
>
> But let us assume the following scenario:
>
> there are two outgoing WAN interfaces: eth0 and eth1.
>
> 1. Outgoing Traffic from eth0 should not be SNAT-ted.
> 2. Outgoing traffic from eth1 should be SNAT-ted.
>
> All WWW traffic gets marked, hits TPROXY redirect rule, and goes to
> TPROXY server.
>
> Case 1 is fine for TPROXY traffic and other traffic.
>
> But in Case 2, when SNAT happens, three-way handshake between TPROXY
> server and Web server is not successful. This issue is only with the
> Web traffic that is originated from TPROXY server (i.e., the server
> with IP_TRANSPARENT option set).
>
> Observation:
>
> 1. TPROXY server sends SYN packet with foreign source IP to WWW server
>
> 2. WWW server sends SYN-ACK to TPROXY server.
>
> 3. TPROXY server is not sending ACK to WWW server that leads to a
> half-open connection.
>
> Please let me know if you require more information.
This is probably a byproduct of the fact that PREROUTING/mangle is
traversed before PREROUTING/nat.
If you SNAT a TCP connection with non-local IP then the return packet on
mangle will have the modified destination IP and thus the socket match
won't find the socket.
For now the only solution I see is modifying your SNAT rule so that
connections initiated by the proxy won't be SNAT-ted and you do the
translation _in_ the proxy. Of course a proper solution would be better on
the long run.
--
KOVACS Krisztian
More information about the tproxy
mailing list