[squid-users] Re: Forwarding loop on squid 3.3.8

On 7/08/2014 3:28 a.m., James Michels wrote:
> El miércoles, 6 de agosto de 2014, Amos Jeffries <squid3_at_treenet.co.nz>
> escribió:
>
>> On 7/08/2014 1:26 a.m., Karma sometimes Hurts wrote:
>>> Greetings,
>>>
>>> I'm trying to setup a transparent proxy on Squid 3.3.8, Ubuntu Trusty
>>> 14.04 from the official APT official repository. All boxes including
>>> the Squid box are under the same router, but the squid box is on a
>>> different server than the clients. Seems that for some reason the
>>> configuration on the squid3 box side is missing something, as a
>>> forwarding loop is produced.
>>>
>>> This is the configuration of the squid3 box:
>>>
>>> visible_hostname squidbox.localdomain.com
>>> acl SSL_ports port 443
>>> acl Safe_ports port 80 # http
>>> acl Safe_ports port 21 # ftp
>>> acl Safe_ports port 443 # https
>>> acl Safe_ports port 70 # gopher
>>> acl Safe_ports port 210 # wais
>>> acl Safe_ports port 1025-65535 # unregistered ports
>>> acl Safe_ports port 280 # http-mgmt
>>> acl Safe_ports port 488 # gss-http
>>> acl Safe_ports port 591 # filemaker
>>> acl Safe_ports port 777 # multiling http
>>> acl CONNECT method CONNECT
>>> http_access allow all
>>> http_access deny !Safe_ports
>>> http_access deny CONNECT !SSL_ports
>>> http_access allow localhost manager
>>> http_access deny manager
>>> http_access allow localhost
>>> http_access allow all
>>> http_port 3128 intercept
>>> http_port 0.0.0.0:3127
>>>
>>> This rule has been added to the client's boxes:
>>>
>>> iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination
>>> 192.168.1.100:3128
>>
>> Thats the problem. NAT is required on the Squid box *only*.
>>
>>
> Ok, but if NAT is required on the Squid box exclusively, how do I redirect
> all outgoing traffic sent to the port 80 over a client to another box
> (concretely the one where Squid runs) without using such NAT?
>

covered in the rest of what I wrote earlier.

Policy routing. AKA make default gateway for port 80 traffic from each
client be the Squid box.
 The easiest way to do that is to simply make Squid box the default
gateway for all clients, and have only Squid box aware of the real
gateway. Requires the Squid box be able to handle the full network
traffic load.
 Harder way is setting default gateway for only port 80 traffic be the
Squid box rest going to real gateway.

http://wiki.squid-cache.org/ConfigExamples/Intercept/IptablesPolicyRoute

>
>>>
>>> 192.168.1.100 corresponds to the squid3 box. In the log below
>>> 192.168.1.20 is one of the clients.
>>
>>
>> When receiving intercepted traffic current Squid validate the
>> destination IP address against the claimed Host: header domain DNS
>> records to avoid several nasty security vulnerabilities connecting to
>> that Host domain. If that fails the traffic is instead relayed to the
>> original IP:port address in the TCP packet. That address arriving into
>> your Squid box was 192.168.1.100:3128 ... rinse, repeat ...
>>
>> Use policy routing, or a tunnel (GRE, VPN, etc) that does not alter the
>> packet src/dst IP addresses to get traffic onto the Squid box.
>>
>>
> I thought packets were not mangled over the same network unless
> specifically done via iptables.

Correct. And you have done that mangling with "-j DNAT" on the client
machines. Squid box does not have access to those client machines
kernels to un-mangle.

> Does that mean that the squid3 box
> currently has trouble resolving the Host domain, i.e. google.com and
> therefore tries relaying to the original packet ip? Seems to resolve it via
> the 'host' or 'ping' commands.
>

Domains do not always resolve to the same IPs. We see a lot of
false-negative results from Host verification for Google and Akamai
hosted domains due to the way they rotate, geo-base, and IP-base DNS
results in real-time. Thus the fallback to original IP.

Amos
Received on Wed Aug 06 2014 - 16:56:46 MDT