Re: [squid-users] NTLM Authentication and Connection Pinning problem

Jeff Foster wrote:
>>> There appears to be a problem with the connection pinning in both
>>> versions squid-2.7.stable7 and
>>> squid-3.1.0.7. I have some network captures that show the client
>>> (IE6) creating multiple TCP
>>> connections to the squid proxy and the proxy creating multiple TCP
>>> connections to an IIS server.
> ....
>>> I have tcpdump traces for both versions available.
>>>
>>> In the 3.1 dump summary, note that the client packet 207 is the server
>>> packet 210.
>>> The server should be on port 37159 and it is on port 37161.
>>>
>>> Can a developer look at this?
>> There are quite a few pinning issues resolved since 3.1.0.7 (beta) was
>> released.
>> Try 3.1.0.16 beta.
>>
>> Amos
>>
>
> Sorry I mis-typed, I am running version 3.1.0.16.
>
> Not sure how connection pinning works. Does it tie a client TCP socket
> to an upstream TCP socket? Or does it tie a client URL to an upstream
> socket?
>
> Jeff F>

'tis complicated.

The simplest view is that it ties a client TCP link, to a destination
domain name.

Warning, technical details ahead. As I understand it...

  It ties each input triplet (client TCP link, client IP, destination
domain name) which has been NTLM or Kerberos auth "signed" by an auth
request/challenge passing through them to a particular output pair
(server TCP link, destination domain) where the auth challenge was
answered correctly.
It stays tied as long as both links are open.

Requires persistent connections to be ON for both servers and clients.

Requires http_port connection-auth=on or =auto

Requires any cache_peer involved to also have connection-auth=on or =auto

These last two requirements are met by default in Squid-3.1.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE7 or 3.0.STABLE23
   Current Beta Squid 3.1.0.16