On 7/28/2012 11:54 PM, Ming-Ching Tiew wrote:
From: Eliezer Croitoru <elie...@ngtech.co.il>
To: squid-users@squid-cache.org
Cc:
Sent: Saturday, July 28, 2012 10:53 AM
Subject: Re: [squid-users] tproxy can't connect to target url after url rewrite
program to different host
On 07/28/2012 02:55 AM, Ming-Ching Tiew wrote:
Tested this with Squid Version 3.1.20-20120710-r10457,
After a simple url_rewrite_program changing from url to
a different host, the communication will not succeed
( using linux bridge with ebtables/iptables for this tproxy
communication ).
The nat intercept mode could succeed.
only for the url?
for me it works fine.
Further testing revealed that if the re-written url is at port 80,
then it works. If the url is changed to a different port, then
it will timeout. Eg
http://dfsdffsa:8080/fsdafsdf
Looks like there is a restriction here, because when squid
opens a connection faking the client (tproxy), the reply since is it
not port 80, it is not coming back to squid.
now that you remind me.
i have seen this kind of problem!!!
it was nasty on squid 3.1.
you can see in iptables connection tracking that squid is opening the
socket but it sends the first syn and wont get the incoming syn from the
destination.
but there are two different situations bridge and routing.
on bridge it's pretty obviates.
you must tell the bridge to "drop" the incoming traffic from of source
port 8080 otherwise it will be bridged to the client and wont get back
to squid.
Regards,
Eliezer
--
Eliezer Croitoru
https://www1.ngtech.co.il
IT consulting for Nonprofit organizations
eliezer <at> ngtech.co.il
