[tproxy] Fwd: Tproxy changes for performing dual NAT

[Arun S]

On 30/10/2007, Tóth László Attila <panther at elte.hu> wrote:
> Hello,
>
> On 2007.10.30., at 10:29, Arun S wrote:
>
> > 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.
> >
> >
>
> Ah, I see. I had the same problem when I used the other version of
> Tproxy4...
>
> In the other version I missed to check a condition (which is not
> important now),  also the incoming tproxied packets didn't arrive to
> the socket that is specified by the TPROXY target. In this case the
> problem is similar to this one. The routing decision happens
> somewhere near the PREROUTING hook (I'd say at the end of the chain
> which may be modified by rules in this chain). First the mangle table
> is checked then the nat table, in both of them the PREROUTING chains,
> then the packet can go to the FORWARD or the INPUT chain if it is not
> dropped previously, depending on the routing decision. The latter one
> fails somehow. This is not a real problem in this case because it can
> be made in an other way.
>
> The "workaround" may be this one:
>
> -   spoof.sin_addr.s_addr = client.sin_addr.s_addr;
> +  spoof.sin_addr.s_addr = inet_addr ("95.75.75.104");

Yes. I already tested this out and as you said, it is fine :)

>
> Hm, did you set the INPUT policy to ACCEPT  the incoming connections?
> I ask it beacuse  you didn't send the output of iptables -L.
>
>
> For instance the following is enough:
> (iptables -F)
> iptables -P INPUT DROP
> iptables -A INPUT -m mark --fwmark 1 -j ACCEPT

Well... all my policies are set to ACCEPT. So I don't think this is
causing trouble,

fyi...

[root at Arun-FC6-SQUID ~]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination


> --
> Attila
>
>
>
>


-- 
Regards,
Arun S.