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

Thu Mar 12 08:13:12 UTC 2015

Hi Amos,

Thank you for the walkthrough..

Instead of having to play with tproxy on haproxy currently, I figured 
i'd try a simpler route..

The purpose of this setup, is to "jump around" a firewall issue with a 
sh#! firewall, which in order to filter http and https traffic 
appearently drops 5-15%.. and in 6 months noone has seem willing/able to 
fix it :(

I've put squid directly on the 10.43.18.181 (previously haproxy) ip - 
and changed to: http_port 80 intercept

I tried this on the client (being on other subnet):
iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination 
10.43.18.181:80

and the traffic looped in exactly the same way :(

Amos Jeffries wrote on 03/10/2015 05:45 PM:
> On 11/03/2015 4:08 a.m., Klavs Klavsen wrote:
>> hmm..
>>
>> I've read the config examples..
>>
>> I would very much like to understand how/why it works, if I've setup a
>> client to route package to squid (instead of trying to send directly)..
>
> I suggest diagramming your network traffic flow, writing down the TCP
> packet src/dst IP:port values on each connection.
>
> "Normal" interception operation showing your loop:
>
> 1) curl thinks its talking to Internet server
>      src ip-of-curl:*
>      dst ip-of-bt.dk:80
>
> 2) NAT diverts the packet to haproxy
>      src ip-of-curl:*
>      dst ip-of-haproxy-machine:*
>
> 3) haproxy knows its talking to Squid
>      src ip-of-haproxy-machine:*
>      dst 10.43.18.165:3129
>
> 4) Squid machine reports un-mangled NAT is ...
>      src ip-of-haproxy-machine:*
>      dst 10.43.18.165:3129
>
> 5) Squid contacts dst-IP to fetch the HTTP request
>      src 10.43.18.165:*
>      dst 10.43.18.165:3129
>
> 6) repeat from 4 (but with src now 10.43.18.165:*) until
>    a) machine runs out of memory,
>    b) machine runs out of TCP sockets,
>    c) machine runs out of disk space logging errors, or
>    d) Squid notices Via header loop and rejects request.
>
>
> A "Normal" connection directly to squid port:
>
>
> 1) curl thinks its talking to Internet server on 10.43.18.165:3129
>      src ip-of-curl:*
>      dst 10.43.18.165:3129
>
> 2) Squid machine reports un-mangled NAT is ...
>      src ip-of-curl:*
>      dst 10.43.18.165:3129
>
> 3) Squid contacts dst-IP to fetch the HTTP request
>      src 10.43.18.165:*
>      dst 10.43.18.165:3129
>
> 4) repeat from 2 (but with src now 10.43.18.165:*) until
>    a) machine runs out of memory,
>    b) machine runs out of TCP sockets,
>    c) machine runs out of disk space logging errors, or
>    d) Squid notices Via header loop and rejects request.
>
>
>
> Confirm it against wireshark packet traces of what is coming *in* to the
> Squid machine.
>
> Squid undoes the NAT mangling done on the machine its running. Any NAT
> changes prior to that is unknowable. NAT un-mangling can sometimes
> appear to work in Squid if haproxy runs on the same machine BUT, some
> NAT lookup requires correct TCP socket and some require particular
> IP:port ordering so its unrelible.
>
>
> The Squid access.log lines with ORIGINAL_DST show what client src-IP and
> dst-IP Squid received after NAT un-mangling. Though you have to take
> care to subtract the duration value from the line timestamp to get the
> order right for loops.
>
>
>>
>> I'm trying to follow this on a test client (haven't gotten it working yet):
>> http://wiki.squid-cache.org/ConfigExamples/Intercept/IptablesPolicyRoute
>> (where squid is amongst the internal clients - actually on it's own vlan
>> - but it's not the default route)
>
> If its on its own VLAN then its not "among the clients".
>
> "among the clients" means a bunch of machines all on the same LAN
> subnet, one of which is the Squid proxy. They can talk directly to each
> other without involving the router so you can hit the triangular routing
> problem and have to account for it in your forwarding and/or NAT rules.
>
> If you have Squid on a separate subnet or VLAN with all packets going
> via the router, that is a DMZ subnet. The router sees all packets and
> can adjusts them right, so triangular routing problem is avoided.
>
>
>>
>> meanwhile I tried pointing to the haproxy - which then forwards requests
>> in tcp mode, to squid server port 3129.
>>
>> If I just send to haproxy directly, I get the loop and this in the
>> accesslog:
>> 1425998994.271      0 10.43.18.165 TCP_MISS_ABORTED/000 0 GET
>> http://www.bt.dk/ - ORIGINAL_DST/10.43.18.165 -
>>
>> when doing:
>> curl -H "Host: www.bt.dk" http://proxy-haproxy-ip/
>>
>> 10.43.18.165 is the ip of squid server behind haproxy.
>
>
> Methinks that haproxy is still sending to the Squid port configured with
> "intercept" option.
>
> A connection between two proxies is explicitly configured. Thus a normal
> forward-proxy connection, no special port flags required.
>
>
> The log line is also showing haproxy to be vulnerable to CVE-2009-0801.
>
> If your Squid and haproxy are recent enough they could use the PROXY
> protocol to exchange the original client connections TCP/IP details.
> I've not tested it for this myself but that may also allow Squid with an
> intercept port to both handle the traffic okay (PROXY protocol override
> the NAT lookups), and protect against the CVE-2009-0801 vulnerability in
> haproxy ('intercept' flags existence makes Squid do the security checks).
>
>
> Amos
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>

-- 
Regards,
Klavs Klavsen, GSEC - kl at vsen.dk - http://www.vsen.dk - Tlf. 61281200

"Those who do not understand Unix are condemned to reinvent it, poorly."
   --Henry Spencer