Squid 2, CARP & WPAD
I cant find any information on this on a few searches, but does wpad based auto-discovery not support virtual IP addresses?
As i've been having a few issues with a CARP array & squid where the traffic will only pass through squid if the wpad specifies the exact IP of a pf in the array, whereas using the CARP IP just doesnt work.
Is there perhaps a binding setting for squid to set?
Ive added the variables:
";http_port PF_1:3128;http_port PF_2:3128;http_port PF_CARP_IP:3128"
to the end of the config section but all it does it cause squid to crash on startup.
Thanks in advance all.
There is no failover with Squid. Not really sure what you are trying to do.
This particular CARP array runs with two PF hosts.
If one server fails for whatever reason, the other kicks in. In BSD world its called CARP, MS world its NLB.
It works for normal net traffic, it works for OpenVPN, and it works for Squid3. However Squid2, when the proxy address client side is set to use the virtual IP of the CARP array, it will not accept a connection.
Whereas if the client is set to use one of the two "real" IPs, it works fine.
Thats what im trying to solve. Not Squid failing over, but supporting multiple incoming IPs for it to be binded too.
If it works with Squid3, then use Squid3. Done. There's noone going to touch totally dead version (completely unsupported upstream and completely dropped from FreeBSD).
I'm sorry but that's not really an answer, considering Squid2 is according to the Pf documentation the only version of the two that is "officially supported"
Additionally, Squid 3 isn't reliable enough and its memory leaks are ridiculous. Its not acceptable to throw tens of GB of RAM at it just so it doesn't crash itself due to bad memory caching - and this is with the default installation settings for squid! No customisations, fresh install.
Squid 2 +wpad is my workaround which apart from this binding issue (im guessing) works fine with minimal memory usage to achieve the same result.
The only "supported" version has about 100 bugs that do NOT exist in the uptodate Squid 3.4 package. For help, kindly contact the pfSense developers who claim to "officially support it".
I'll take my chances here for a while ;)
Anyone else any ideas or comments?
^^^ There's the code. Happy fixing. (And, I'd seriously encourage you to get the claimed "official support" - noone touched the superbuggy code for 2,5 years. "Stable" and "officially supported". ROFLMAO.)
P.S. The package won't exist on 2.3 anyway, all of this is just a completely waste of time.
ha ha, so the correct squid.conf variables requires a bug fix in squids actual code???
I get what your saying but as said, this is likely just a syntax issue in the conf, if it is indeed possible to do (which the documentation suggests it is).
Yes. The squid.conf is always regenerated from the GUI configuration (saved in config.xml) whenever you save it, or whenever the package resync gets run for other reasons. Messing with the .conf via shell will get you nowhere. Also, reading the Squid documentation is required. Things valid with 3.4 absolutely are NOT guaranteed to work with 2.7, and vice versa. You're dealing with prehistoric, shitty, dead code.
KOM last edited by
According to ESF, Squid is NOT officially supported. They will not help you with it. Been there already.
Well, I've been told they "officially" support the Squid 2.x thing when I submitted a PR changing the status from "stable" to "unsupported" in the package manager… Didn't investigate further. The thing clearly is dead unmaintained code no matter what's "officially" stated somewhere. Worse, pretty much none of the fixes that have been done between 2.7.x and 3.4.x packages has ever hit the "officially supported" Squid 2.7...
That a shame, two broken squid packages.
Kinda need to hope that 2.3 isnt too far off.
As its been quite buggy and the current releases, whilst improving, still has this memory leak issue amongst others.
And no its not trolling, not considering the rigmarole that myself and many others have had with it.
Its not to devalue the work being done on it by the likes of doktornotor, but the fact remains is there are bugs, most of which cant be helped as the package version is either old, or not fixed upstream, but there are bugs.