Re: [squid-users] Re: Traffic redirection

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Fri, 27 Jul 2012 17:10:20 +1200

On 27/07/2012 7:28 a.m., Abhishek Chanda wrote:
> Hi Amos,
>
> I do not have a "intercept" with http_port. Here is my config:
>
> maximum_object_size 10240 KB
> http_port 80 accel defaultsite=cona-server vhost
> cache_peer 192.168.122.11 parent 80 0 no-query originserver name=myAccel
> acl our_sites dstdomain cona-server
> http_access allow our_sites
> cache_peer_access myAccel allow our_sites
> cache_peer_access myAccel deny all
> acl manager proto cache_object
> acl localhost src 127.0.0.1/32 ::1
> acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
> 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 manager localhost
> http_access deny manager
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
> http_access allow localhost
> http_access deny all
> http_port 3128
> coredump_dir /var/spool/squid3
> refresh_pattern ^ftp: 1440 20% 10080
> refresh_pattern ^gopher: 1440 0% 1440
> refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
> refresh_pattern (Release|Packages(.gz)*)$ 0 20% 2880
> refresh_pattern .
>
> I am still not sure why Squid needs the original source.

CVE-2009-0801, accurate security controls based on destination, logging,
etc.

> Here is what
> I understand: given a topology like this, (Squid is in transparent
> mode)

Ah. NO.

Your Squid is in reverse-proxy mode (port with "accel" option) and also
in forward-proxy mode (port with no options)

Your firewall is performing DNAT on the packets, but there is no
transparent mode handling enabled in Squid.

> Client ------- Squid --------- Server
> there will be an iptable rule at Client to do a DNAT and change
> destination address to that of Squid. When Squid receives the packets,
> it can do its lookups and send the packets back to Client (it can get
> Client's address from the packets).

Here you hit what is called triangular routing:

   client A contacts server B but packets gets NAT'd from (A->B) to
proxy (A->C). The response from proxy is a packet C->A

   client A was talking to B, so its firewalls and systems are prepared
to accept responses from B->A. But what actually arrives is C->A which
are not valid and gets dropped.
   The connection hangs.

You need to ensure your NAT operation is symmetrical. Packets C->A get
converted back to B->A on the response flow. This is what the mandatory
MASQUERADE or SNAT rules do in iptables examples.

When you fix this I think you will see a lot of invalid-request
responses from Squid to the client ... because port-80 origin server
traffic has an entirely different syntax than port-3128 proxy traffic.

> If a lookup fails, it will get the
> server's address from config and get content from the server. So, I
> expected, if I have a OpenFlow flow to re-write IP addresses (and not
> use iptable rule) it will work in the same way. The controller cannot
> change NAT table at the Squid box.

Correct. When performed outside the Squid box you effectively have two
networks connected by a NAT relay. The only thing that matters there is
that the triangular routing does not occur.

>
> When the client tries to contact the server, the traffic is
> re-directed to Squid using a flow. At this point nothing happens at
> the client. Once the flow times out and is deleted, the client gets
> the content from the server. I am not sure why would Squid relay the
> request to itself and loop (though, that seems to be the case here!).
> Can you please explain?

With the above config there is no transparent, so Squid will not be
connecting directly to itself unless its own IP/hostname is in the
packet headers (CVE-2009-0801).

But, the same behaviour appears when Squid contacts a server and some
external machine (OpenFlow controller) DNATs those requests back to
Squid. You must have some form of bypass/skip configured on the DNAT to
prevent that from happening.

Amos
Received on Fri Jul 27 2012 - 05:10:34 MDT

This archive was generated by hypermail 2.2.0 : Fri Jul 27 2012 - 12:00:02 MDT