[squid-users] cache_peer - multiple ones
Hi, After searching the archives, I've decided to ask here. We have setup a Debian Etch box which uses squid to access an upstream proxy run by the education authority. They have given us a username and password and it all works on port 8080 (after challenging us for our Active Directory username and password). We have the line: cache_peer 8080 parent 7 stuff) - I do not have access to it here. Our web browser then points to the Debian box as a proxy on 10.180.8.4:8080 - web browsing is fine. The problem arises when we want to access 443/https websites. The LEA require that we connect again through 8080 but use Squid to point to 443 - so I have added another line. cache_peer 443 parent 7 Now this threw up an error along the lines of having two cache_peer names the same. So we edited the hosts file in DNS setting a name to resolve to the same IP address. The line now reads: cache_peer sslproxy 443 parent 7 We thought this would work - but it didn't, so we edited the cache_peer_access line to say 'cache_peer_access sslproxy allow CONNECT'. Everything seems to be working. However when we try and connect to the 443 website it challenges us again for the AD username and password. Upon entering this the browser challenges us again and again and again - simply not letting us through. I wonder if anyone has any ideas why this would be. If I have not explained it properly please do let me know and I will provide more information. Many thanks in advance, Gareth Edmondson
Re: [squid-users] cache_peer - multiple ones
hi Henrik - answers inline... Henrik Nordstrom wrote: tis 2007-05-01 klockan 22:49 +0100 skrev Gareth Edmondson: Now this threw up an error along the lines of having two cache_peer names the same. So we edited the hosts file in DNS setting a name to resolve to the same IP address. The line now reads: cache_peer sslproxy 443 parent 7 There is a name= option to cache_peer to solve this without having to fake host names.. Thanks for the advice here. I read about this name= option earlier in the archives - but I got the impression from previous posters that it was in version 3 of squid and not the stable version that ships with Debian Etch. The stable version is 2.6.5-6. A quick look at debian.org reveals that 3.0.PRE5-5 is there. I have not tried this because we have been advised to stick with the stable branch. We thought this would work - but it didn't, so we edited the cache_peer_access line to say 'cache_peer_access sslproxy allow CONNECT'. You also need to deny CONNECT from the other.. Okay - I think we may have done this. The lines looked something like this cache_peer_access sslproxy allow CONNECT cache_peer_access sslproxy deny all cache_peer_access deny CONNECT cache_peer_access allow all I'm not sure they are in the right order. Everything seems to be working. However when we try and connect to the 443 website it challenges us again for the AD username and password. Upon entering this the browser challenges us again and again and again - simply not letting us through. What does your access.log say? I shall take a look in work tomorrow. Cheers Gareth
Re: [squid-users] cache_peer - multiple ones
Henrik Nordstrom wrote: tis 2007-05-01 klockan 23:41 +0100 skrev Gareth Edmondson: Thanks for the advice here. I read about this name= option earlier in the archives - but I got the impression from previous posters that it was in version 3 of squid and not the stable version that ships with Debian Etch. The stable version is 2.6.5-6. It's in 2.6 and later. cache_peer_access sslproxy allow CONNECT cache_peer_access sslproxy deny all cache_peer_access deny CONNECT cache_peer_access allow all I'm not sure they are in the right order. Looks fine. order of cache_peer_access is important, but only per peer. The order of the peers is not important. Everything seems to be working. However when we try and connect to the 443 website it challenges us again for the AD username and password. Upon entering this the browser challenges us again and again and again - simply not letting us through. One more thing, have you added trust between Squid and the peer for forwarding of proxy authentication? See the login option to cache_peer. Regards Henrik Here is an extract of my access.log file - what is the difference between a HIT and a MISS in this scenario? 117813.463 0 127.0.0.1 TCP_HIT/200 506 GET http://communities.rm.com/forums/skins/communities/images/message_gradient_header.gif - NONE/- image/gif 117813.515 53 127.0.0.1 TCP_MISS/404 1952 GET http://communities.rm.com/favicon.ico - DEFAULT_PARENT/webcluster.education.swansea.sch.uk text/html 117815.152111 127.0.0.1 TCP_MISS/302 1302 GET http://communities.rm.com/forums/member/default.aspx - DEFAULT_PARENT/webcluster.education.swansea.sch.uk text/html 117815.198 3 127.0.0.1 TCP_MISS/000 3112 CONNECT communities.rm.com:443 - DEFAULT_PARENT/proxyssl - 117818.229 3 127.0.0.1 TCP_MISS/000 3112 CONNECT communities.rm.com:443 - DEFAULT_PARENT/proxyssl - 117821.481 3 127.0.0.1 TCP_MISS/000 3112 CONNECT communities.rm.com:443 - DEFAULT_PARENT/proxyssl - You can see clearly where I have attempted to access a 443 website - yet it still asks me to authenticate against the AD with my username and password. The problem must lie with my authentication modules. GJE
Re: [squid-users] cache_peer - multiple ones
Hi Amos Thanks for that. The lines are as follows: #TAG: cache_peer_access cache_peer_access proxyssl allow CONNECT cache_peer_access proxyssl deny all cache_peer_access deny CONNECT cache_peer_access allow all As for the cache_peer lines they are as follows: #TAG: cache_peer cache_peer parent 8080 7 no-digest no-query no-net-db-exchange default login=username:password cache_peer proxyssl parent 443 no-digest no-query no-net-db-exchange default login=username:password Where username and password are our values. proxyssl is defined in the hosts file because I don't quite understand how to use the name= tag in Squid (I must read up about it). >From some tests we have run, we can tell that the Squid proxy is not sending the proxy authorisation headers (username and password) to the upstream proxy SSL proxy. I'm assuming this is due to a configuration error. The passwords for the two proxies (8080 and 443) are the same as they always have been. Can anyone gleam anything from that? Cheers Gareth
