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

[Daniel]

>>
>
>From: "Balazs Scheidler" <bazsi at balabit.hu>
>
>> 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.
>> 
>
>I should have mentioned in my previous post these points  :-
>
>The problem persists irregardless of whether I set up policy routing
>or not and it is independent of what mark value I used.
>
>I have tested many times the simplest case where I do not 
>have any policy routing  and only one default route. 
>
>So certainly this is not a case of the user-level routing problem.
>
>Regards.
>
>

I'm kinda confused...

Which version exactly are you discussing?

In balabit site[1], tproxy needs iptable_tproxy and hacks route code, but in KOVACS Krisztian's webpage[2], 
the tproxy patch use policy route to make non-local sockets work without both NAT and iptable_tproxy.

PS: I hope to see a tproxy-4.0.4 patchset before tproxy being merged into kernel 2.6.25. ;)

[1]http://www.balabit.com/downloads/files/tproxy/
[2]http://people.netfilter.org/hidden/tproxy/

Regards
  
Daniel
2007-12-11