Is this issue still unresolved?
After reading the whole thread and getting back to the first post I really 
don't understand the issue.
OK so google search "foo" didn't helped to understand how to install and 
configure Squid-Cache right?
You got to the right place!

Now if you don't plan to run Squid-Cache on-top of a Linux system, on what OS 
specifically do you want to run Squid-Cache on-top?
Also what type of hypervisor are you using for your VM?(XEN, VMWARE, KVM, other)
If you want to use a BSD flavored OS you should stick with the OS recommended 
For OpenBSD it's PF.
For FreeBSD it's either PF or IPFW but there is something regarding PF and IPFW 
and multiple CPU's on the past and I'm not sure what is the state of it 
The last time I tested(a year ago) PF was working fine on FreeBSD 10+11 but had 
some issue with virtio NIC's which Debian had a similar issue.
If you are using a BSD OS and not planning to set it up for above 1Gbit link 
then just use an Intel E1000 nic to make things just work as expected.

If there is a need for a test I have a lab ready to test the issue with:
Linux\Windows \BSD Client's
Linux\BSD Router with Squid on-top of it.

When I will receive more details I might be able to clear some doubt's.


Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261

-----Original Message-----
From: squid-users [] On Behalf 
Of Amos Jeffries
Sent: Thursday, February 8, 2018 10:13
Subject: Re: [squid-users] Squid 3.x or 4.x acting as a transparent http proxy 
(NOT https)

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 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 TCP_MISS/302 333 HEAD
> - HIER_DIRECT/ - ("-" "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
> 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: on LAN side, on WAN side ]
> That router has a firewall script on it that says:
> ======================
> #!/bin/sh
> 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
> 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
> (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.
> *
> *

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

squid-users mailing list

squid-users mailing list

Reply via email to