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
