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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
