Bug #2591
closed
Squid3 can't listen on a CARP VIP
0%
Description
The squid3 package allows syncing between HA peers, but .../squid.xml only allows selection of physical interfaces, and does not permit listening on a CARP VIP. So what's the point in having the XMLRPC sync capability, then?
Running "2.1-BETA0 (amd64) built on Tue Aug 14 12:18:46 EDT 2012 FreeBSD 8.3-RELEASE-p4" with squid3 pkg version "3.1.20 pkg 2.0.5_3".
Updated by Chris Buechler over 12 years ago
- Target version deleted (
2.1) - Affected Version deleted (
2.1)
Updated by Chris Buechler over 12 years ago
probably better off posting this to the packages board on the forum, the maintainers tend to not look here.
Updated by Kill Bill about 9 years ago
Please, read this post (and the entire thread there): https://forum.pfsense.org/index.php?topic=46067.msg256634#msg256634
Listening on CARP VIP just doesn't make sense, there's nothing to failover here with Squid.
Close this bug, please.
Updated by Adam Thompson about 9 years ago
That's nice, but nothing in that thread addresses the problem; JimP completely missed the point. And I believe you're dead wrong - there is something to failover here with Squid.
Browsers are configured to talk to a proxy at a known IP address. Browsers do not have the capability (except through a WPAD script) to failover to another configured proxy IP address. Therefore, if I have a pfSense HA pair running Squid, the only LAN-side IP address that fails over from system A to system B is the CARP VIP.
The aim is to not have to reconfigure every single browser when an HA failover takes place. I don't care about state, I only care about Squid still being reachable at that single configured address.
And, my original question remains - and is also not addressed by JimP's response in that thread - what's the point of config sync on a package that can't usefully fail over?
Updated by Kill Bill about 9 years ago
The XMLRPC sync is there to synchronize configuration. You will NOT get any failover with Squid, as already explained on the thread... Use WPAD or whatever.
Updated by Jeroen van Gelderen over 8 years ago
For those getting bit by the missing CARP interfaces, a viable workaround is to
- Bind Squid to Loopback (127.0.0.1) interface.
- Create a port forward from <CARP IP>:3128 to 127.0.0.1:3128.
- Have your users hit <CARP IP>:3128.
You will obviously not get any kind of graceful/stateful failover (i.e. all in-transit HTTP transfers will be aborted) but when your end-users retry their HTTP request (or when their webapp retries it in the background) they will succeed and not call you to complain at 03:00.