[tproxy] Fwd: Tproxy changes for performing dual NAT

[Arun S]

Hi,

On 30/10/2007, Tóth László Attila <panther at elte.hu> wrote:
> Hello,
>
> On 2007.10.30., at 8:13, Arun S wrote:
>
> > Hi Attila,
> >
> > I have a problem with tproxy4 that I downloaded from the given links.
> >
> >
>
>
> >
> > Scenario 2:
> > Testing SNAT with TPROXY:
> >
> > The following ip and iptable rules are added:
> > ip rule add fwmark 1 lookup 100
> > ip route add local 0.0.0.0/0 dev lo table 100
> >
> > iptables -t mangle -N DIVERT
> > iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
> > iptables -t mangle -A DIVERT -j MARK --set-mark 1
> > iptables -t mangle -A DIVERT -j ACCEPT
> >
> > iptables  -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY
> > --tproxy-mark 0x1/0x1 --on-port 8080
> >
> > iptables -t nat -A POSTROUTING -o eth0 -s 20.20.20.4 -j SNAT --to
> > 95.75.75.104
> >
> > Output:
> >
> > [root at Arun-FC6-SQUID ~]# ./listIpt.sh
> > POSTROUTING - NAT
> > Chain POSTROUTING (policy ACCEPT 1254 packets, 167219 bytes)
> >     pkts      bytes target     prot opt in     out     source
> >      destination
> >        0        0 SNAT       all  --  *      eth0    20.20.20.4
> >    0.0.0.0/0           to:95.75.75.104
> >
> > MANGLE
> > Chain PREROUTING (policy ACCEPT 27667 packets, 2716681 bytes)
> >     pkts      bytes target     prot opt in     out     source
> >      destination
> >      252    21872 DIVERT     tcp  --  *      *       0.0.0.0/0
> >    0.0.0.0/0           socket
> >        0        0 TPROXY     tcp  --  *      *       0.0.0.0/0
> >    0.0.0.0/0           tcp dpt:80 TPROXY redirect 0.0.0.0:8080 mark
> > 0x1/0x1
> > Chain DIVERT (1 references)
> >     pkts      bytes target     prot opt in     out     source
> >      destination
> >      254    21952 MARK       all  --  *      *       0.0.0.0/0
> >    0.0.0.0/0           MARK set 0x1
> >      254    21952 ACCEPT     all  --  *      *       0.0.0.0/0
> >    0.0.0.0/0
> >
> > In this case, SNAT is happening properly. But ACK is not happening as
> > part of the three-way handshake. So the client hangs around till the
> > timeout happens.
> >
> >
>
> You didn't write what kind of TCP traffic doesn't work. If it comes
> from the LAN1 network and the destination port is 80, it will go to
> the TPROXY target to squid. All other traffic coming from the LAN1 is
> independent from the tproxy patches, also it should work.

True. Traffic from LAN1 and dport 80 gets redirected to TPROXY server
and as you said, all other traffic is independent of tproxy marks.
>
> If the actual snat-ted traffic's local endpoint is the squid, it can
> bind to that IP address (to any IP if the TRANSPARENT sockopt is set).
>
>
> > Please find attached the sample-TPROXY server code with this.
>
> 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.


>
> --
> Attila
>
>
>
>


-- 
Regards,
Arun S.