[tproxy] Clarification on tproxy4 usage
hi2arun at gmail.com
Wed Aug 27 17:04:34 CEST 2008
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.
2008/8/27 Ming-Ching Tiew <mingching.tiew at 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
>> iptables -t nat -A POSTROUTING -o eth2 -p tcp --dport 80 -j SNAT --to
>> 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.
> 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
> 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.
> tproxy mailing list
> tproxy at lists.balabit.hu
More information about the tproxy