From: "Balazs Scheidler" <bazsi@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