[tproxy] tproxy4, kernel 2.6.22 and squid-2.6.stable13

[Balazs Scheidler]

On Mon, 2007-12-10 at 17:27 +0800, Ming-Ching Tiew wrote:
> From: "Ming-Ching Tiew" <mingching.tiew at redtone.com>
> >
> > You are right, it might not be 'tproxy' at all. Because when squid makes a
> > outbound connection, the modified squid will use IP_FREEBIND
> > to spoof an outgoing IP. There is no tproxy redirect involved at all. It's
> > purely an outbound connection binded to a foreign IP using IP_FREEBIND.
> >
> 
> To put things in perspective, this is my conclusion now :-
> 
> 1. IP_FREEBIND has problem working with mangle table MARK
>     in the OUTPUT chain.
> 
>     This problem exists before Kovac's patch to fix SNAT. So I
>     believe all current users of tproxy 4.0.3 on kernel 2.6.22
>     will see the same problem.
> 
> 2. When there is an iptables rule which marks the mangle OUTPUT
>     chain, the packets cannot leave the computer at all if the
>     source IP is a foreign IP. This is not about unable to get replies.
> 
>     This has been confirmed using tcpdump.
> 
> 3. In case (2), if the source IP is a local IP, then there is no
>     problem, even if it is an ip_freebind socket and there is FWMARK
>     in the socket buffer.
> 
>     So it is not so much about FWMARK or freebind socket per se. It's
>     more too do with FWMARK packets seems to be taking a different
>     route compared to without, and that route has problem with foreign
>     IP in the source.
> 
> 4. My very humble guess is that it's all to do with routing of FWMARK
>     packets with foreign IP in the source. But I am not knowledgible
>     enough to debug further.

Probably this is the case, if the packet generated by a tproxied
connection is visible on the OUTPUT chain, it means that tproxy did its
job.

You can check advanced routing rules by listing:

ip rule ls

You'll probably see lines like this:
32765:  from all fwmark 0x64 lookup 100 

This means that all packets with the specified fwmark will use a
potentially different routing table than the ones without this mark. If
the referenced routing table does not have a route to the specified
subnet (or has a blackhole route), then the packet will not leave the
box.

You can list the referenced routing table by issuing:

ip route ls table 100

where 100 is the name/id of the routing table in question.

-- 
Bazsi