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.