Re: [squid-users] Intercept @ Squid-3.4.6

Same configuration with Squid-3.2.13 and the same problem:

connect(11, {sa_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr("SQUIDIP")}, 16) = -1 EINPROGRESS (Operation now in
progress)

Something related to configure line?

On Wed, Jul 23, 2014 at 5:54 PM, Roberto O. Fernández Crisial
<roberto.fernandezcrisial_at_gmail.com> wrote:
> Nicolas,
>
> I do not use client and server on the same machine.
>
> The Squid 3.1.10 has been installed via "yum". The Squid 3.4.6 has
> been compiled using: "./configure --prefix=/usr/local/squid-3.4.6
> -enable-icap-client --enable-ssl --enable-ssl-crtd
> --with-default-user=squid --enable-ltdl-convenience
> --enable-linux-netfilter--enable-snmp --enable-esi
> --with-filedescriptors=16384 --with-dl --with-openssl --with-pthreads
> --enable-arp-acl --enable-follow-x-forwarded-for"
>
> I'm going to try with Squid 3.2.16 and let you all know.
>
> Best,
>
> On Wed, Jul 23, 2014 at 5:15 PM, Nicolás <nicolas_at_devels.es> wrote:
>> Hi Roberto,
>>
>> El 23/07/2014 20:54, Roberto O. Fernández Crisial escribió:
>>
>>> Hi guys,
>>>
>>> I hope you're doing fine. I'm trying to intercept HTTP requests on
>>> Squid 3.4.6 but I'm going crazy. Is there any http_port parameter
>>> change between 3.1.10 and 3.4.6?
>>>
>>> I have 3.1.10 working fine, here are the examples:
>>>
>>> IPTABLES CONFIGURATION (Global config)
>>> -A PREROUTING -s 10.1.0.0/16 -p tcp -m tcp --dport 80 -j DNAT
>>> --to-destination SQUIDIP:3129
>>>
>>>
>>> With Squid 3.1.10
>>>
>>> SQUID CONF
>>> http_port 3128 transparent
>>> http_port 3129 intercept
>>>
>>> START SQUID 3.1.10
>>> 2014/07/23 16:06:38| Accepting intercepted HTTP connections at
>>> 0.0.0.0:3128, FD 12.
>>> 2014/07/23 16:06:38| Accepting intercepted HTTP connections at
>>> 0.0.0.0:3129, FD 13.
>>>
>>> CURL
>>> curl http://www.ciudad.com.ar -x http://SQUIDIP:80
>>>
>>> STRACE
>>> accept(13, {sa_family=AF_INET, sin_port=htons(34330),
>>> sin_addr=inet_addr("10.1.100.158")}, [16]) = 9
>>> getsockname(9, {sa_family=AF_INET, sin_port=htons(3129),
>>> sin_addr=inet_addr("SQUIDIP")}, [16]) = 0
>>> connect(15, {sa_family=AF_INET6, sin6_port=htons(80),
>>> inet_pton(AF_INET6, "::ffff:200.42.143.77", &sin6_addr),
>>> sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINPROGRESS (Operation now
>>> in progress)
>>>
>>> STOP SQUID 3.1.10
>>>
>>>
>>> Now with Squid 3.4.6
>>>
>>> SQUID CONF
>>> http_port 3128
>>> http_port 3129 intercept
>>>
>>> START SQUID 3.4.6
>>> 2014/07/23 16:06:05| Accepting HTTP Socket connections at
>>> local=[::]:3128 remote=[::] FD 19 flags=9
>>> 2014/07/23 16:06:05| Accepting NAT intercepted HTTP Socket connections
>>> at local=[::]:3129 remote=[::] FD 20 flags=41
>>>
>>> CURL
>>> curl http://www.ciudad.com.ar -x http://SQUIDIP:80
>>>
>>> STRACE
>>> accept(20, {sa_family=AF_INET6, sin6_port=htons(34428),
>>> inet_pton(AF_INET6, "::ffff:10.1.100.158", &sin6_addr),
>>> sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 8
>>> getsockname(8, {sa_family=AF_INET6, sin6_port=htons(3129),
>>> inet_pton(AF_INET6, "::ffff:SQUIDIP", &sin6_addr), sin6_flowinfo=0,
>>> sin6_scope_id=0}, [28]) = 0
>>> connect(10, {sa_family=AF_INET, sin_port=htons(80),
>>> sin_addr=inet_addr("SQUIDIP")}, 16) = -1 EINPROGRESS (Operation now in
>>> progress)
>>>
>>> STOP SQUID 3.4.6
>>>
>>>
>>> I see in Squid 3.4.6 the squid process tries to conect to itself on
>>> port 80. With Squid 3.1.10 works fine (connets to reomte server). Any
>>> ideas?
>>>
>>> Thank you all in advance.
>>>
>>> Best,
>>
>>
>> In my case I'm running v. 3.3.8, but I'm having the same issue than you. The
>> packets are correctly DNATed from the client to the squid box, but once
>> there, squid3 seems to try to connect to itself several times and keeps
>> adding its 'visible_hostname' to the Via header, causing a forwarding loop.
>>
>> I've followed these instructions to achieve it:
>> http://wiki.squid-cache.org/ConfigExamples/Intercept/AtSource
>>
>> Recently, the document got updated adding a new iptables OUTPUT rule, you
>> could try and see if it works to you (it didn't work to me, though).
>>
>> Regards,
>>
>> Nicolás
>>
Received on Wed Jul 23 2014 - 21:07:46 MDT