On 06/30/2011 02:17 PM, Amos Jeffries wrote:
On Thu, 30 Jun 2011 11:22:57 +1000, tony.carter@xxxxxxxxxxxxxxxxxxx
wrote:
Greetings,
Squid Cache: Version 2.7.STABLE9
Access URL: https://remote.phau.com.au:987/grains/default.aspx
With no intervening proxy server, the above site returns an untrusted
SSL
certificate warning which, once accepted, takes me through to a login
dialog.
With the proxy server in the chain, squid returns a "Connection to
165.228.126.196 Failed " - the untrusted cert warning page is not
returned.
The squid logs display the following -
1309240053.271 60029 148.145.157.200 TCP_MISS/504 0 CONNECT
remote.phau.com.au:987 - DIRECT/165.228.126.196 -
There is nothing displayed in the cache log.
The research I've done typically reports as follows (and also that there
is little I can do about it save contacting the target servers admin):
<snip> This server (squid) did not receive a timely response from an
upstream server it accessed to deal with your HTTP request.
This usually means that the upstream server is down (no response to the
gateway/proxy), rather than that the upstream server and the
gateway/proxy
do not agree on the protocol for exchanging data. </snip>
Could it be the certificate warning which is causing the timeout and
if so
are there ways to configure squid to deal with it.
No. The problem is happening right down at the TCP level. Squid sends
a TCP SYN packet and nothing comes back.
Things to look at are firewall rules dropping packets to or from port
987. Or possibly packet routing differences. On any hardware between
your squid box and the remote site which is not also between your
working client machine and that same site.
Amos
987 is an unusual port to host a website on. As Amos points out,
firewalls are quite likely a possible candidate for dropping traffic.
The other thing to consider is SELinux. Default policies on RHEL won't
allow Squid to make a connection on port 987.
