[squid-users] Connection pinning in Squid 3.1

Hi,

I'm having trouble with connection pinning. I'm on SUSE Linux Enterprise
(SLES) 11 SP3, so I'm stuck with squid3-3.1.12-8.16.18.1 at the moment.

My scenario: Firefox, Squid and a parent proxy (McAfee Web Gateway). The
parent proxy offers "Proxy-Authenticate: Negotiate" and
"Proxy-Authenticate: NTLM" to provide for single sign on. Firefox jumps
on "Negotiate" the first time but the parent proxy knows about Firefox's
problem and offers only "NTLM" the next time.

This scenario has been working with Squid 2.7 for quite some time (years
actually). Now I'm in the process of migrating to Squid 3.1.

The configuration condenses to:
        http_port 8080
        acl me src 1.2.3.4/32
        http_access allow me
        http_access deny all
        cache_peer myparent.dmz.prv parent 8080 0 no-query \
                no-digest login=PASS name=myparent.dmz.prv
        cache_peer_access myparent.dmz.prv allow
        always_direct deny all
        never_direct allow all

I tried with "connection-auth=on" at "http_port" and "cache_peer" but
that did not help.

The name= clause seems redundant, it is an artifact of a local load
balancer configuration. I removed it to eliminate possible
interferences. Originally it was:
        cache_peer 127.0.0.1 parent 8090 0 no-query \
                no-digest login=PASS name=myparent.dmz.prv

I can see with tcpdump that Squid not even remotely maintains a 1:1
relationship between inbound and outbound TCP connections. Instead, it
seems to jump on the first free outbound connection for nearly every
incoming request. This reliably breaks the NTLM authentication scheme
and as a result password requests keep popping up in the browser.

I could probably resort to 2.7.STABLE5, which is delivered with SLES 11
SP3 too. But that seems to be the cowards way :-) and I still have some
time to do some tests before moving towards production.

So if anyone would take the time and guide me through some debugging I
would be happy to help sorting this out.

Kind regards,
Robert
Received on Mon Jun 30 2014 - 17:22:27 MDT