[tproxy] Fwd: Tproxy changes for performing dual NAT
Arun S
hi2arun at gmail.com
Tue Oct 30 12:03:28 CET 2007
Okay. I will give a shot at it here.
Regards,
Arun S.
On 30/10/2007, Tóth László Attila <panther at elte.hu> wrote:
>
> On 2007.10.30., at 11:40, KOVACS Krisztian wrote:
>
> > 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.
> >
>
> Ops, I forgot the routing table numbered 100. If the socket match
> doesn't find the socket, it won't be marked to 1 also the packet's
> destination won't be handled as a local address this is why it fails:
> ip rule add fwmark 1 lookup 100
> ip route add local 0.0.0.0/0 dev lo table 100
>
> --
> Attila
>
>
>
--
Regards,
Arun S.
More information about the tproxy
mailing list