Re: squid as a local proxy for kerberos authentication

On 2026-03-04 10:01, Christoph Mathys wrote:
> Hello everyone,
> 
> I'm considering installing Squid on user devices to authenticate
> against corporate proxies using Kerberos. This approach allows me to
> set http_proxy=localhost:3128 for various tools, enabling transparent
> authentication.
> 
> When it works, it works quite well!
> 
> However, before corporate proxies can be reached or resolved, users
> need to establish a VPN connection to the corporate network.

Understood.


> I've noticed that Squid doesn't handle situations well when it cannot
> resolve or connect to cache_peers. 

Please note that we do not know how you define "well" in this context.


> I'm wondering if the retry behavior
> can be tweaked so that Squid retries connecting to cache_peers
> whenever a new request is received, or after a short delay (e.g., when
> a user realizes the VPN isn't up, connects, and then refreshes with
> F5).

That behavior is already implemented AFAICT. I realize that what you 
observe does not match what you want to see, but it seems to match what 
you describe in the above paragraph. The associated [peerProbeIsBusy() 
and caller] code can be interpreted as literally matching your "upon new 
request or after a short delay" description!..

The devil is in the details. In this case, I suspect that at least two 
details are relevant:

1. It is important to distinguish "Squid starts trying to connect" from 
"Squid finishes trying to connect". Squid does not support multiple 
_concurrent_ cache_peer probes. If a cache_peer probe takes, say, 30 
seconds, the peer will be treated as dead for those 30 seconds. Roughly 
speaking, another probe will be started when/if there is another 
potential need for that cache_peer after the current probe finishes.

2. Probes that can mark a cache_peer as "alive" are not a part of a 
regular HTTP transaction. They are triggered by regular transactions and 
(re)configurations, but regular transactions do not _wait_ for probes to 
finish and do not reuse probe connections. Probing is a "background" 
activity.


Going forward, I see several paths:

A: Configure user devices to start Squid _after_ the user establishes "a 
VPN connection to the corporate network". I do not know whether that is 
possible in your environment, but, if it is, it would be a relatively 
clean solution that does not require Squid development.

B: Add a cache_peer "aggressive-probes" option to re-probe a still-DEAD 
peer without waiting for an HTTP request that may use that peer. This 
should be a fairly straightforward development project. This will not 
solve all the problems[^B2], but it should help a lot.

C: If you really want Squid to _stall/pause_ an incoming HTTP request 
until at least one eligible cache_peer is available, then you will need 
to write quite a bit of complicated code (AFAICT) that would be 
difficult to make official. The idea just goes against how Squid peer 
selection code is structured/designed. I do not recommend this path.


HTH,

Alex.

[^B2]: Ideally, you also do not want to make Squid service available to 
user requests until cache_peers are successfully probed. Any requests 
should immediately fail (because Squid is not listening for them) while 
Squid is still probing. I may even have code that accomplishes something 
very similar, but it is currently stuck in the Squid Project backlog.


> I wanted to ask here first before diving into the code or implementing
> a workaround.
> 
> Currently, my workaround is to manually restart Squid when it decides
> that no cache_peers are available (IIRC, returning http 500).
> 
> I'm on macOS, and since this is a corporate setup, my options are
> somewhat limited.