Re: [squid-users] tproxy can't connect to target url after url rewrite program to different host

From: Eliezer Croitoru <>
Date: Sun, 29 Jul 2012 01:18:44 +0300

On 7/28/2012 11:54 PM, Ming-Ching Tiew wrote:
> From: Eliezer Croitoru <>
> To:
> 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

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.


Eliezer Croitoru
IT consulting for Nonprofit organizations
eliezer <at>
Received on Sat Jul 28 2012 - 22:19:21 MDT

This archive was generated by hypermail 2.2.0 : Sun Jul 29 2012 - 12:00:03 MDT