[squid-users] squid "internal?" loop - with no firewall nat going on..?

[Amos Jeffries]

On 11/03/2015 2:19 a.m., Klavs Klavsen wrote:
> Amos Jeffries wrote on 03/10/2015 01:50 PM:
>> On 11/03/2015 1:29 a.m., Klavs Klavsen wrote:
>>> Hi,
>>>
>>> I just setup a squid trying to get it to work in intercept mode..
>>>
>>> I seem to hit some squid internal loop where it goes haywire internally
>>> somehow?
>>
>> You have explicitly configured Squid instructing it that traffic
>> arriving on port 3129 has been intercepted.
>>
>> You then sent Squid a port-80 syntax message with TCP packet destination
>> IP:port of 127.0.0.1:3129.
>>
> port 80 syntax?
> 
>> It is for this reason that all our interception tutorials state in bold
>> that its a very good idea to firewall the 3129 port such that no
>> software, even localhost may send traffic directly into it.
>>
> 
> ahh.. I was hoping to have a loadbalancer in front of squid (haproxy) -
> to have failover, if squid server should fail..

In which case you would NOT be intercepting by Squid. The LB device
would be doing that. The haproxy would be configured to pass traffic to
Squid port 3128.

Though, what happens if the haproxy device fails? all you've done is
shift the bottleneck from Squid to both Squid and haproxy.

Squid has built in mechanisms for auto-restart if anything goes wrong.
Its sometimes hard to see that anything has happened at all from a
client perspective. The admin will just see some graph spikes in the
service records and (if they look) a log message.


> 
> I'm trying to read and understand:
> http://wiki.squid-cache.org/SquidFaq/InterceptionProxy#Concepts_of_Interception_Caching
> 
> 
> when nat'ing - doesn't squid just get the rewritten package (which would
> have port 3129 in the tcp dest. port field?)

Squid gets a NAT-mangled TCP/IP SYN packet. It then uses the kernel to
undo that mangling in order to contact the original destination IP on
the outgoing connection from Squid.

If the incoming detail (after un-mangling) was Squid itself, things loop.

> 
> ie. how can it discern a package send directly to port 3129 - with data
> containing f.ex.:
> GET / HTTP/1.1
> Host: www.bt.dk
> 
> with one just sent directly to that port?

It can't. Which is why NAT existence is a bunch of security vulnerabilities.


Squid is using the Via header to detect if a request has already been
through this same proxy N times. Which is why Via is a mandatory header
in HTTP/1.1. But all that does is prevent the loop DoS'ing the entire
machine and all other services on it - the bad client has still DoS'ed
itself.

> 
> I seem to be failing to understand wherein the difference lies :(
> 
> I can see that one can choose to use GRE encapsulation - but that is
> stated to be optional..

GRE is just a tunnel that can be used to divert traffic to the Squid
machine for NAT to operate on. Usually used as part of WCCP routing
setups, but its just a tunnel.

Amos