When troubleshooting user internet connection issues with a specific URL, that are returning the very unhelpful Blue Coat “TCP Error” message, I normally pop into the Blue Coat ProxySG appliance and run a test from the appliance to the URL in question. I will log into the ProxySG appliance via SSH, and issue the command below:
test http get http://url-with-the-issue.xyz
From this command you will receive enough information to identify if the site is having issues, maybe your external IP is blacklisted, perhaps there is a firewall upstream (not too likely, but possible), or maybe the proxy is looking for authentication, and the user simply has no way of knowing (appliances requiring internet access, but without browser – direct connect). Below are some of the results you will encounter, and waht you can do to identify the true problem.
SUCCESFUL HTTP GET REQUEST – The browser is provided with a ‘301 Moved Permanently’ message, and we are rerouted to the permanent address and receive a successful webpage.
This message identifies that the ProxySG is not having an issue resolving the site, and the proxy isn’t neccesarily the problem at this point, and you can move on to client configurations, upstream devices, blacklists, etc.
proxysg.company-x.com#test http get http://google.com Type escape sequence to abort. Executing HTTP get test * HTTP request header sent: GET http://google.com/ HTTP/1.0 Host: google.com User-Agent: HTTP_TEST_CLIENT * HTTP response header recv'd: HTTP/1.1 301 Moved Permanently Location: http://www.google.com/ Content-Type: text/html; charset=UTF-8 Date: Thu, 15 Dec 2011 23:16:58 GMT Expires: Sat, 14 Jan 2012 23:16:58 GMT Cache-Control: public, max-age=2592000 Server: gws X-XSS-Protection: 1; mode=block X-Frame-Options: SAMEORIGIN Content-Length: 219 Connection: close Measured throughput rate is 4.10 Kbytes/sec HTTP get test passed
FAILED HTTP GET REQUEST – The browser is provided a ‘503 Service Unavailable’ message and we receive a long timeout, then the standard web browser message “Page Unavailable”, or similar message.
This message identifies that the ProxySG can resolve the site, but is unable to provide a webpage to the browser. This is usually due to a destination server issue, destination firewall setting (usually only if the target company is verrrry cautious about site visitors), or a possible blacklisting of your external IP address.
proxysg.company-x.com#test http get http://google.com Type escape sequence to abort. Executing HTTP get test * HTTP request header sent: GET http://someurlsomewhere.com HTTP/1.0 Host: someurlsomewhere.com User-Agent: HTTP_TEST_CLIENT * HTTP response header recv'd: HTTP/1.1 503 Service Unavailable Cache-Control: no-cache Pragma: no-cache Content-Type: text/html; charset=utf-8 Proxy-Connection: close Connection: close Content-Length: 1329 Measured throughput rate is 0.03 Kbytes/sec HTTP get test passed
SUCCESFUL HTTP GET REQUEST – REQUIRES AUTHENTICATION – The browser is provided a ‘401 Authorization Required’ message, which means 1 of 2 things. Either your internal ProsySG is requiring you to authenicate, or the destination webpage requires authentication. However, if the user is not seeing a pop-up message explaining they need to authenticate, it may be a system that does not have a browser, and cannot display the authentication message to the user. This normally means that the user might need to contact the destination to request credentials, talk to their system vendor to verify it is ‘proxy aware’, or perhaps the source IP of the user system may be added to the internal ProxySG’s ‘Do Not Authenticate’ list in the VPM.
proxysg.company-x.com#test http get http://google.com Type escape sequence to abort. Executing HTTP get test * HTTP request header sent: GET http://someurlsomewhere.com HTTP/1.0 Host: someurlsomewhere.com User-Agent: HTTP_TEST_CLIENT * HTTP response header recv'd: HTTP/1.1 401 Authorization Required Date: Wed, 11 Aug 2010 15:40:31 GMT Server: Apache/2.2.3 (CentOS) WWW-Authenticate: Basic realm="For Acme Health only..." Content-Type: text/html; charset=iso-8859-1 Cache-Control: proxy-revalidate Content-Length: 479 Connection: close Proxy-support: Session-based-authentication Measured throughput rate is 4.50 Kbytes/sec HTTP get test passed
I may add a few more messages and how to troubleshoot through them on the ProxySG, but for now, good luck troubleshooting!!! 😉