We just put in a CSC v6.3 and occassionally when browsing out we get an HTTP 503 Unavailable error, but when we reload the page it loads. Anyone else experience something like this? Any known fixes?
This happens with well-known sites such as cisco.com, google.com, etc.
If you remove the module from the flow - meaning when the CSC module is not scanning the http traffic you never see these 503 erros?
Make sure the CSC module is using a proper DNS server IP address to resolve names.
well i haven't "removed" the CSC from the flow... but we didn't have the issue before the CSC was put in a few days ago... and the DNS is correct, it's our internal server.
Directly connected to the CSC module in the same segment? If not pls. change the DNS to 18.104.22.168 and see if this resolves the issue.
When the CSC module returns a 503 error it means that the connection between the CSC module socket and the webserver was reset or timed out. How often does it happen? If it happen always (google) never loads then we need to figure out what the proxied connection from the CSC to the web server fails.
First, lets talk about how the module works. The CSC acts like a transparent proxy. When you browse to Google you actually are connecting to a TCP socket on the CSC module. Once you form that connection (browser to csc) and send your HTTP GET request, the CSC checks to make sure the page is allowed etc. If all is well, the CSC then opens a socket (mimicking the same source ip as the first socket) to the destination webserver (Google). Once the content is transferred, the module scans the content and then passes it back on the first socket.
If the connection between the CSC and the webserver is broken (timeout or torn down prior to us sending the GET request on the socket), we get a 503.
Just as a test (since I have seen this is some strange corner cases) can you load up Firefox and reproduce the problem. After doing so, go to 'about:config' in Firefox and filter for "network.http.keep-alive" and set it to false. Close Firefox and try to reproduce the problem again. Just on a hunch.. If this 'fixes' it for Firefox, then my hunch is that that we are trying to pass GET request on closed sockets (something I have seen in prior cases). There are some tricks we can do in CSC version 6.3.1172.3 to tweak connection behavior to prevent this... but we can talk about that when the time comes...
If the Firefox trick does not help, let me know and we can re-tool for a different approach...
I found out the users were not typing www. in the URL of their browser, they were just putting "google.com". So far, that seems to have fixed it! Thanks for everyone's assistance. I'll post again if the issue creeps up again.
We have this behaviour to and also with sites with www Furthermore we need to test if our domains function without www.
And it is dreadfully slow (sites that download normally within 300 ms take 4 seconds with URL filtering ...)
if anyone has a good idea.
Make sure your DNS server that is specified in the CSC is reachable and can resolve all the web site addresses.
Also, for the slowness, try tweaking the HTTP settings for scanning (such as increasing the threshold for sizes, etc). That normally works.
Thanks for your answer. The DNS server are reachable (and are really close by and fast, checked that already). I can only tweak ate Scanning tab and then only for large files. Or do you know other places where I can tweak. The websites I am talking about are really small and still take 4 sec (read this one to https://supportforums.cisco.com/message/3251153 )
If it does a check to the CSC server for every GET in a page (which it looks like it does, because that explains the amount of DNS wait time firebug sees, most likely trend Micro tells the Browser it is doing a DNS ). I think that is pretty sloppy programming you could keep already checked URL's in an array ...
Anyway I hope we find an answer otherwise I have two Anti-X modules for sale :-)