The proxy could not connect to the destination in time.
We are in the process of setting up moving from our appliance based Web Gateway 6.x setup to a virtualized 7.x setup. At the moment we have four VM's on ESX set up in a centralized management system and loadbalanced through BigIP.
Unfortunately I have not been able to go into production with this yet as there are a couple of problems.
1. Cannot Connect The proxy could not connect to the destination in time.
This happens maybe once every few days, I've noticed it when loading articles under http://www.vg.no. Hitting a refresh makes the page load just fine.
2. An internal error occured while processing your request.
Error Message: (20100) The connection downloading the file was terminated.
This happens often during downloads, I've seen it quite a few times on sourceforge downloads.
We've had similar timeout messages about DNS before as well but I haven't seen that again. The appliances have been reinstalled with 7.3 and uses a ruleset with few modifications. Cache is disabled. The above errors happen regardless if I add my client in the "global whitelist" rule and skip antimalware scanning.
What is going on here? How can I troubleshoot this?
Re: The proxy could not connect to the destination in time.
1.) This usually means that MWG was not able to connect to the server, of better said MWG says "Hello" and the server does not respond fast enough. You could experiment with some timeout settings and increase them slightly to see if this help to solve the issue. Additionally it would be possible to create a packet capture when the problem occurs which will allow further inspection of at which stage of the communication the destination does not respond, which then leads to assumptions where to look next.
2.) Are you using Progress Pages? Is the load balancer configured in a way that the user always talks to the same MWG? When using Progress Pages the client sends a GET request to the configured Proxy (in this case the load balancer) to update the status of the download. If you are using 4 MWGs and MWG A is downloading the file, this update request can ONLY be sent to MWG A. If the request goes to MWG B this instance of MWG does not know anything about the download and will send back an error, as indicated.
You need to either ensure that session stickiness is given (e.g. a client PC always talks to the same MWG instance) or disable all features which require session stickiness, such as Progress Pages (use data trickling instead).