Re: [tproxy] Clarification on tproxy4 usage
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
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.
Arun Srinivasan wrote:
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?
I hope you will not be offended during this troubleshooting thingie for an experienced person like you however I am trying to rule out every possibility here :- Did you flush your routing cache when you started without SNAT and then later you added SNAT ? ( Most kernels are compiled to use cached route ! ). Also what is your iptables policy - perhaps it's good idea to keep policy to ACCEPT in this testing stage. ( Likely that you have already done so ). Regards.
I did clear the cache and verified. Also all my iptables policies are ACCEPT by default. However no luck. Btw, could you tell me the latest version of tproxy and iptables that you have verified. So that I could give a shot at it. Thank you. 2008/8/28 Ming-Ching Tiew <mingching.tiew@redtone.com>:
Arun Srinivasan wrote:
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?
I hope you will not be offended during this troubleshooting thingie for an experienced person like you however I am trying to rule out every possibility here :-
Did you flush your routing cache when you started without SNAT and then later you added SNAT ? ( Most kernels are compiled to use cached route ! ).
Also what is your iptables policy - perhaps it's good idea to keep policy to ACCEPT in this testing stage. ( Likely that you have already done so ).
Regards.
_______________________________________________ tproxy mailing list tproxy@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/tproxy
-- Regards, Arun S.
Arun Srinivasan wrote:
I did clear the cache and verified. Also all my iptables policies are ACCEPT by default. However no luck.
Btw, could you tell me the latest version of tproxy and iptables that you have verified. So that I could give a shot at it.
Thank you.
/I used iptables-tproxy-200710091749.diff and tproxy-kernel-2.6.25-20080519-165031-1211208631.tar.bz2 /
participants (2)
-
Arun Srinivasan
-
Ming-Ching Tiew