Thanks for the quick response. Yes... the interface name is a typo and it is eth1. Well, as you said, I killed Squid and did what you said. I could see the pkts getting SNATted. Also I don't see any issues with routing/iptables as the setup for normal HTTP interception (no tproxy in squid.conf) works fine. There is also another observation. With tproxy enabled, I could not even connect to a cache_peer that is running on the same host (UML 2). i.e., The squid is configured to connect to another proxy that runs on the same UML 2. But it fails. However, with tproxy disabled, this case also works fine. Any thoughts? 2008/8/27 Ming-Ching Tiew <mingching.tiew@redtone.com>:
Arun Srinivasan wrote:
Scenario 2: Now am gonna add a SNAT rule on UML 2 to SNAT traffic out through eth1 with src IP 100.100.200.2 Say, iptables -t nat -A POSTROUTING -o eth2 -p tcp --dport 80 -j SNAT --to 100.100.200.2
In this case, the traffic is not hitting the rule that is added.
However, if I remove tproxy related configuration from the UML and Squid, the traffic hits the rule like a charm.
Firstly,
I supposed this just a typo, eth2 is supposed to be eth1 ?
iptables -t nat -A POSTROUTING -o eth2 -p tcp --dport 80 -j SNAT --to 100.100.200.2
Secondly,
I would like to make some suggestion to the testing.
Perhaps you could just keep your existing rules but kill squid, and issue the http requests from UML2 and do some sniffing on eth1.
This is a simplified test, yet it represents how squid would perform http request on behalf of the client. This test will verify if there is any problem with iptables or routing. By right you should see that the SNAT rule is traversed.
Cheers
_______________________________________________ tproxy mailing list tproxy@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/tproxy
-- Regards, Arun S.