> I am using 2.6.STABLE20 for Windows. I am not using the transparent > option, nor am I using accelerator mode. Based on what I have read, Squid > should by default allow a client to access HTTPS pages. > > This is not working with my setup, and I'm trying to figure out why. HTTP > pages work fine when I use the proxy from a client machine, or when I try > from the proxy server itself. HTTPS pages work fine from the proxy server, > but from a client machine I am getting "page cannot be displayed." > > > I am including a section from cache.log, as well as pieces from my > squid.conf that may or may not be relevant (using defaults for options > I've not included here). > > Thanks in advance for any help. > Lets run through whats happening here... > 2008/06/03 15:57:02| aclCheck: checking 'http_access allow > company_network' > 2008/06/03 15:57:02| aclMatchAcl: checking 'acl company_network src > 192.168.0.0/255.255.0.0' > 2008/06/03 15:57:02| aclMatchIp: 'CLIENT.EXTERNAL.IP' NOT found > 2008/06/03 15:57:02| aclMatchAclList: no match, returning 0 > 2008/06/03 15:57:02| aclCheck: checking 'http_access allow server10' > 2008/06/03 15:57:02| aclMatchAcl: checking 'acl server10 src > SERVER10.EXTERNAL.IP/255.255.255.255 192.168.10.35/255.255.255.255' > 2008/06/03 15:57:02| aclCheck: checking 'http_access allow allowed_hosts' > 2008/06/03 15:57:02| aclMatchAcl: checking 'acl allowed_hosts src > CLIENT.EXTERNAL.IP/255.255.255.255 192.168.2.79/255.255.255.255 > SQUIDSERVER.EXTERNAL.IP/255.255.255.255' > 2008/06/03 15:57:02| aclMatchIp: 'CLIENT.EXTERNAL.IP' found > 2008/06/03 15:57:02| aclMatchAclList: returning 1 > 2008/06/03 15:57:02| aclCheck: match found, returning 1 > 2008/06/03 15:57:02| cbdataUnlock: 00C2B688 > 2008/06/03 15:57:02| aclCheckCallback: answer=1 > 2008/06/03 15:57:02| cbdataValid: 01511C80 > 2008/06/03 15:57:02| The request CONNECT www.google.com:443 is ALLOWED, > because it matched 'allowed_hosts' The request is being permitted by the allowed_hosts ACL. A short time later the tunnel gets setup to www.google.com:443 > 2008/06/03 15:57:02| sslStart: 'CONNECT www.google.com:443' > 2008/06/03 15:57:02| comm_open: FD 18 is a new socket > 2008/06/03 15:57:02| fd_open FD 18 www.google.com:443 <blah,blah,blah opening bits and DNS lookup> > 2008/06/03 15:57:02| ipcacheCycleAddr: www.google.com now at 72.14.205.104 > 2008/06/03 15:57:02| connect FD 18: (10035) WSAEWOULDBLOCK, Resource > temporarily unavailable. > 2008/06/03 15:57:02| comm_connect_addr: FD 18 connection pending <blah, blah> temporary problem... > 2008/06/03 15:57:02| comm_connect_addr: FD 18 connected to > 72.14.205.103:443 ... retry and it works! > 2008/06/03 15:57:02| comm_remove_close_handler: FD 18, handler=00429BA1, > data=0154A690 > Send 39 bytes of something to google. > 2008/06/03 15:57:02| sslWriteClient: FD 17, 39 bytes to write > 2008/06/03 15:57:02| sslWriteClient: FD 17, 39 bytes written ... waiting for the response. > 2008/06/03 15:57:02| sslReadClient: FD 17, reading 16384 bytes at offset 0 > 2008/06/03 15:57:02| sslReadClient: FD 17, read -1 bytes > 2008/06/03 15:57:02| cbdataLock: 016153E8 > 2008/06/03 15:57:02| sslReadClient: FD 17: read failure: (10054) > WSAECONNRESET, Connection reset by peer. OOPS! www.google.com:443 sent a TCP_RESET to you. > 2008/06/03 15:57:02| sslAbort: FD 17/18 ... shutting down the connection. As you can see its not your config causing problems. It's google denying you a connection access. Possibly because of the way Squid is setting up the tunnel. Probably because of what is being sent over it. Amos
