Re: [squid-users] cache_peer - multiple ones
Just seems odd. I have put in the following cache_peer upstream proxy name parent 8080 7 no-digest no-query no-netdb-exchange default login=username:password name=proxy cache_peer upstream proxy name parent 443 7 no-digest no-query no-netdb-exchange default login=username:password name=proxyssl and then further down: cache_peer_access proxyssl allow CONNECT cache_peer_access proxyssl deny all cache_peer_access proxy deny CONNECT cache_peer_access proxy allow all So browsing through Squid, onto the upstream proxy on port 8080 works fine. When I try and access login.live.com on port 443/https then I get challenged for my upstream details again - . These details have been confirmed as correct and are the same username and password as they always have been. I must be missing something simple then if there is no bug. GJE
Re: [squid-users] cache_peer - multiple ones
Hi Chris, Okay - I've followed those instructions and squid reloads the configuration file without any issues. Browsing on port 8080 works, but once again 443 is challenging me for my credentials even though I have turned off all authentication. The thing about squid is, it is selecting the correct proxy (or cache_peer), however, it is not sending the proxy authentication headers (login details) to the upstream proxy in the case of the HTTPS (CONNECT method) requests. I have no idea why not, and suspect a bug/glitch in squid it's self. Could this be looked at? I'm not sure how to do this. Or how I prove it it a bug. Cheers GJE On Fri May 4 0:08 , Chris Robertson [EMAIL PROTECTED] sent: Gareth Edmondson wrote: 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). That would be the reason you are being prompted for password a second time. Squid has no way of knowing that these are the same upstream proxy. What you want to do is... cache_peer parent 8080 7 no-digest no-query no-net-db-exchange default login=username:password name=proxy cache_peer parent 443 7 no-digest no-query no-net-db-exchange default login=username:password name=proxyssl cache_peer_access proxyssl allow CONNECT cache_peer_access proxyssl deny all cache_peer_access proxy deny CONNECT cache_peer_access proxy allow all ...which informs Squid that even though both proxy definitions use the same machine, they have different purposes, and defines what those purposes are. 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 Chris
Re: [squid-users] cache_peer - multiple ones
[EMAIL PROTECTED] wrote: Hi Chris, Okay - I've followed those instructions and squid reloads the configuration file without any issues. To be clear, you are using the same domain name or IP address in both definitions of the parent proxy, correct? You are no longer using the real domain for one, and a fabricated domain (found only in the hosts file), or a second DNS A record for the other. Browsing on port 8080 works, but once again 443 is challenging me for my credentials even though I have turned off all authentication. Where did you turn off authentication? At the parent proxy, or in the cache_peer definition? The thing about squid is, it is selecting the correct proxy (or cache_peer), however, it is not sending the proxy authentication headers (login details) to the upstream proxy in the case of the HTTPS (CONNECT method) requests. If you have removed the login=username:password argument from the cache_peer directive, you won't (I think) get prompted for a password. You'd just be denied by the upstream proxy for not providing authentication credentials. I have no idea why not, and suspect a bug/glitch in squid it's self. Could this be looked at? I'm not sure how to do this. Or how I prove it it a bug. I'll see if I can find the time to set up a test lab with a similar setup (parent proxy listening on two ports, both require authentication, child proxy using one port for SSL) and report back. Some days afford more free time than others. :o) Cheers GJE Chris
Re: [squid-users] cache_peer - multiple ones
[EMAIL PROTECTED] wrote: Hi Chris, Okay - I've followed those instructions and squid reloads the configuration file without any issues. After setting up a test machine, and looking through the archives of this thread, it appears as though my instructions were... Less than perfect. No surprise there. :o) Here's the revised version... cache_peer webcluster.education.swansea.sch.uk parent 8080 7 no-digest no-query no-netdb-exchange default login=PASS name=proxy cache_peer webcluster.education.swansea.sch.uk parent 443 7 no-digest no-query no-netdb-exchange default login=PASS name=proxyssl cache_peer_access proxyssl allow CONNECT cache_peer_access proxyssl deny all cache_peer_access proxy deny CONNECT cache_peer_access proxy allow all The above settings will cause your child proxy (the Debian Etch machine) to: * acknowledge authentication requests from the parent proxy and pass them to the end user * use port 443 on the parent proxy for all CONNECT traffic * use port 8080 on the parent proxy for all other traffic and * use the first (successful) authentication credentials for all traffic. My test parent proxy was using the basic authentication scheme. You mentioned Active Directory, but also that prompts were required for authentication, so I am assuming this is not going to be the issue. If you want to use one login and password pair for all traffic, change login=PASS to login=user:password* on both cache_peer definitions, and you will not be prompted for a password at all. Cheers GJE Chris *Where you replace the word user with the actual username and the word password with the associated password.
Re: [squid-users] cache_peer - multiple ones
Gareth Edmondson wrote: 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 original upstream name deny CONNECT cache_peer_access original upstream name 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 Ah, check your squid.conf very carefully. The acl are checked in order and if any of the acl before the 'http_access allow CONNECT' or 'http_access allow SSL_Ports' requires auth, then the auth will be checked for. To get CONNECT out without auth you will need to configure any acl with auth _after_ the allow CONNECT. Amos
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 upstreamproxyaddress deny CONNECT cache_peer_access upstreamproxyaddress allow all As for the cache_peer lines they are as follows: #TAG: cache_peer cache_peer upstreamproxyaddress 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
Re: [squid-users] cache_peer - multiple ones
Gareth Edmondson wrote: 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 upstreamproxyaddress deny CONNECT cache_peer_access upstreamproxyaddress allow all As for the cache_peer lines they are as follows: #TAG: cache_peer cache_peer upstreamproxyaddress 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). That would be the reason you are being prompted for password a second time. Squid has no way of knowing that these are the same upstream proxy. What you want to do is... cache_peer upstreamproxyaddress parent 8080 7 no-digest no-query no-net-db-exchange default login=username:password name=proxy cache_peer upstreamproxyaddress parent 443 7 no-digest no-query no-net-db-exchange default login=username:password name=proxyssl cache_peer_access proxyssl allow CONNECT cache_peer_access proxyssl deny all cache_peer_access proxy deny CONNECT cache_peer_access proxy allow all ...which informs Squid that even though both proxy definitions use the same machine, they have different purposes, and defines what those purposes are. 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 Chris
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 original upstream name deny CONNECT cache_peer_access original upstream name 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
[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 upstreamproxyname 8080 parent 7 and then all the other 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 upstreamproxyname 443 parent 7 and then all the other stuff 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 and then all the other stuff 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
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 and then all the other stuff There is a name= option to cache_peer to solve this without having to fake host names.. 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.. 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? Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
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 and then all the other stuff 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 original upstream name deny CONNECT cache_peer_access original upstream name 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
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 original upstream name deny CONNECT cache_peer_access original upstream name 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 signature.asc Description: Detta är en digitalt signerad meddelandedel
