From: "Ming-Ching Tiew" <mingching.tiew@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. This is as far as I can go. Anyone who finds it otherwise please let me know. :-) I will appreciate further pointers to further debug the problem. Regards.