[squid-users] Squid 3.x or 4.x acting as a transparent http proxy (NOT https)

[Amos Jeffries]

On 08/02/18 10:11, setuid wrote:
> I'll start with the pointedly easy stuff: Squid > 2.6 (tested 3.4, 3.5,
> 4.0 on Ubuntu Xenial, Debian Jessie, FreeSBD 11.1 using iptables, pf,
> ipf, ipfilter) does not work at all, when configured as a transparent
> proxy. Full stop.
> 
> I went through hundreds of posts on dozens of forums, blogs and other
> resources, tried dozens and dozens of configurations suggested by those
> posts, tried all 3 firewall options on BSD, tried two versions of Ubuntu
> and the various versions of Squid from the apt repos, as well as those
> in BSD's ports.
> 
> All of them, 100%, fail in _exactly_ the same way, no matter what my
> configuration was set to. That result, is that _every single http
> request I make_ when Squid is configured as a transparent proxy, results
> in the following response being logged:
> 
> ======================
> 	07/Feb/2018:15:10:59 -0500.213      0 192.168.1.1 TAG_NONE/400 3583 GET
> / - HIER_NONE/- text/html ("-" "-")
> ======================
> 
> When I point a client directly at the proxy, using a browser, curl or
> anything else, I see:
> 
> ======================
> 	07/Feb/2018:15:12:56 -0500.875     82 192.168.1.1 TCP_MISS/302 333 HEAD
> http://www.java.com/ - HIER_DIRECT/www.java.com - ("-" "curl/7.47.0")
> ======================
> 
> These were the same exact request against the same exact Squid instance.

Lets start with the obvious then. HEAD is Not the same as GET. These are
*different* requests. Therefore something major is wrong with your
understanding of the situation.


> If I use Squid 3.5 on Ubuntu or 3.5 and 4.0 on BSD, the logged entry is
> _identical_ for every single http request I make, regardless of origin.
> 
> My Squid configuration is 100% default, identical to the generic config,
> with the exception of the following lines:
> 
> ======================
> http_port 3128
> http_port 3129 intercept
> tcp_outgoing_address 192.168.1.25
> debug_options ALL,9
> ======================
> 
> I've tried all of the obvious links, blogs and resources I could Google
> up, and 100% of them fail to function as described. Most people I've
> seen on the forums who attempt to get this working, throw their hands up
> in defeat and end up configuring the proxy directly on every client that
> needs it.
> 
> My current environment looks like this:
> 
> [ wireless router: 10.0.1.1 on LAN side, 192.168.1.1 on WAN side ]
> 
> That router has a firewall script on it that says:
> 
> ======================
> #!/bin/sh
> PROXY_IP=192.168.2.25
> PROXY_PORT=3128
> LAN_IP=$(nvram get lan_ipaddr)
> LAN_NET=$LAN_IP/$(nvram get lan_netmask)
> 
> iptables -t nat -A PREROUTING -i br0 -s $LAN_NET -d $LAN_NET -p tcp
> --dport 80 -j ACCEPT
> iptables -t nat -A PREROUTING -i br0 -s ! $PROXY_IP -p tcp --dport 80 -j
> DNAT --to $PROXY_IP:$PROXY_PORT
> 
> iptables -t nat -I POSTROUTING -o br0 -s $LAN_NET -d $PROXY_IP -p tcp -j
> SNAT --to $LAN_IP
> iptables -I FORWARD -i br0 -o br0 -s $LAN_NET -d $PROXY_IP -p tcp
> --dport $PROXY_PORT -j ACCEPT
> ======================
> 
> This takes every packet that hits the router on :80, and sends it to my
> Squid server on .25, which mangles it and sends it back to 192.168.1.1
> (router), and onward back to client who requested it.
> 

No. This takes HTTP (port 80 syntax) and sends it to a remote proxy
expecting explicit-proxy syntax.


> When I was using 2.6 (without large_file support), I was using this same
> exact configuration, but http_port was set to 'accel', and I didn't need
> _any_ NAT/routing rules on the squid side at all. It all "Just Worked(tm)".


It also "Just Worked" for anyone attacking your network via
CVE-2009-0801 methods. And would provide them with an effective
invisibility cloak while doing so (original IP:ports destroyed by the NAT).
 Not exactly desirable behaviour.



> 
> Now I need to jump through hoops to do pf incantations of rdr/direct-to
> (but direct-to and direct-reply aren't supported on FreeBSD's pf, only
> OpenBSD's pf supports that syntax), and iptables PREROUTING and
> POSTROUTING mojo (also fails).
> 

You need simply *route* traffic properly in the way the Internet was
designed to work. Instead of abusing NAT.

When that is done properly the NAT happens *only* as the final step to
get the traffic into the Squid process by the machine/device/VM Squid is
running on.


> Here's a list of some of the resources I've tried, with 100% failure in
> every case. There are dozens more that I've lost in my browser history now.
> 
> * https://wiki.squid-cache.org/ConfigExamples/Intercept/Ipfw
> *
> https://wiki.squid-cache.org/SquidFaq/InterceptionProxy#Interception_Caching_packet_redirection_for_OpenBSD_PF

Hmm. I see that page is updated and missing quote a few things. Thanks
for bringing this to attention.

Amos