On 2014-01-28 06:18, Peter Warasin wrote:
hi guys
I configured a transparent proxy environment using TPROXY following the
howto on the squid wiki http://wiki.squid-cache.org/Features/Tproxy4
I setup a tproxy port in squid on port 18080 and created the following
iptables rule:
-A PREROUTING -p tcp --dport 80 -j TPROXY --on-port 18080 --tproxy-mark
0x1/0x1
But squid does never see packets coming in.
So I tried with the following tool:
https://github.com/kristrev/tproxy-example
The same, packets are not seen.
By chance I tried to redirect to port 80 instead of 18080, in order
that
redirection does not happen at all, and then packets were seen by the
tproxy-example tool.
Seems that redirection is not working correctly or not at all.
I proved with iptables logging rules that routing is correct, because
packets are coming in the INPUT chain instead of FORWARD and are marked
as they should be.
Good.
Are there any rules in there that would prevent port 18080 packets
being accepted?
Also I see the following debug output when compiled the tproxy iptables
modules with -DDEBUG:
xt_TPROXY: redirecting: proto 6 194.232.104.141:80 ->
192.168.11.15:18080, mark: 1
which I would say means redirection actually *is* taking place, or
perhaps debug messages are only correct while redirection is not (?).
I tried with both, squid 3.2.1 and 3.3.8 and with kernels 2.6.32 and
3.2.54 and combinations. Always the same result.
Kernel 2.6.32 is older than the minimum version (*.37). The older 2.6
have some TPROXY commits, but have bugs such as ICMP packets about
TPROXY connection issues not being handled by the kernel properly which
result in these strange packet disappearances).
I have also been seeing some posts about regressions and memory leaks in
the netfilter mailing lists these last few months. I'm not sure if those
issues made it to the stable kernels, but would be late 3.10+ versions
if so.
Does anyone have some hints where I could look at in order to solve
this?
My first port of call would be the packet forwarding settings of the
kernel and later iptables rules. Since TPROXY does not alter the packet
IPs they have "non-local" values when passing through all the normal
kernel forwarding permit/deny checks between the "mangle" table and the
Squid process socket.
I think RP filter is only affecting the outgoing traffic, but that could
be worth checking as well.
Amos
