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

[KOVACS Krisztian]

Hi,

On Wed, Dec 12, 2007 at 09:20:41AM +0800, Ming-Ching Tiew wrote:
> To repeat this is what I suggest :-
> 
> 1. compile a kernel 2.6.22 with the patch on the balabit website.
> 2. compile iptables 1.3.8 using the iptables patch on the balabit website.
> 3. configure the system with a default route without SNAT so that
>    it can access internet. No policy routing needed.
> 4. download this small program which I posted earlier :-
> 
> https://lists.balabit.hu/pipermail/tproxy/2007-December/000618.html
> 
>    And compile it as 'spoof'.
> 
> 5. No need to set up bridge, ebtables or even tproxy targets (but you
>     could set it up too it does not matter ). The objective to the test is
> to
>     check if packets could get out of the box, so we are not worried about
>     return path. Use 'tcpdump' to check the outgoing.
> 
> 6. Invoked the program this way :-
> 
>         # ./spoof 192.168.1.5 72.14.235.99
> 
>     Where 192.168.1.5 could be a local IP or a foreign IP and
>                  72.14.235.99 is any website's IP address.
> 
>     Without MARK in mangle OUTPUT chain, whether it's local IP or foreign
>     IP, packets could get out of the box ( check it using tcpdump ).
> 
>     With MARK, only local IP could have packets going out of the box.
> 
>     To mark outgoing packets, do this :-
> 
>             iptables -t mangle -A OUTPUT -j MARK --set-mark 5
> 
> Looking forward to your testing results.

Ah, the penny dropped. So you're stating that a simple MARK rule on the
OUTPUT chain ruins your egress path?

I guess that's because chaning the mark in the mangle table causes
Netfilter to try and re-route the packet. There's some magic in
ip_route_me_harder() that for some reason does an ip_route_input() on your
packet ruining everything... I think this was originally meant as a way of
overcoming the source address restriction in ip_route_output() but in the
current version of the tproxy patches from Balabit those checks are
commented out anyway.

Could you try what happens if you change ip_route_me_harder() in
net/ipv4/netfilter.c so that it does the same ip_route_output() call even
if addr_type != RTN_LOCAL?

-- 
KOVACS Krisztian