Our end users occassionally get this error message from the Proxy that are proving hard to track down.
The Proxy could not connect to the destination in time
But if the user hits refrersh a few times, the page displays fine (usually). I have opened 2 or 3 tickets up for this issue, any it's usually the same thing. Send us a packet capture when it happens...
Its not predictable, so its hard to catch when it happens, and it could be any page, its not always the same page for every user.
I had such an issue and found the reason in IPv6. I missed to disable "Use other protocol version as fallback" within Configuratio -> Proxies -> DNS Settings -> IP protocol version preference. For some sites it requested the AAAA record which is not reachable for us.
As long as you don't have a fully supported IPv6 Internet access I'd recommend to disable all IPv6 related settings (not only for MWG).
Hope this helps.
Regrading the problem of having a dump when the errors occurs, here is a little "howto have rolling tcpdump". In this example customer had sporadic NTLM Pop Ups therefore we have filtered the dump for 445 and DNS (most likely related):
################ rolling tcpdump ###########################
Log into the Gateway with a tool like putty as the root user. Browse to /var and verify that you have enough free space to store the captures using 'df -k'. With the syntax I've provided, you will need 2GB of free space on var, but that can be changed, keeping in mind that if you reduce how many captures will be stored by too much, you may have the worthwhile tcpdump deleted before you stop the rolling capture.
[root@wwapp ~]# nohup tcpdump -Z root -s 0 -i any port 445 or port 53 -C 100 -W 20 -w capturefilename.pcap &
-C is how large the capture can be before a new one is started in MB
-W is how many captures will be stored before the oldest is deleted for a new capture to start.
-port 445 is for active directory and 53 is for dns
-the other parameters should remain unchanged beyond the file name
After putting in the command, after you hit enter you'll see 'nohup: appending output to 'nohup.out' and then just hit enter again to get the commandline back. Once you want to stop the capture, run 'ps aux | grep tcpdump' and get the process ID for the rolling capture, then run 'kill -9 processID' to stop the rolling capture. The captures will be in /var/empty/
Message was edited by: skloepping on 9/10/13 1:36:20 PM CEST
Try to avoid the -9 on kill unless it is necessary.
Kill without it is like asking the process to clean up its stuff and go commit suicide where it won't make a mess. Adding the -9 is like shooting the process and only it knows where it left things behind - they may stay there until a reboot.
Other than that, the rolling tcpdump is great. If you get really crafty you can write a script to watch a log for error messages (may need to create said log) and then save the appropriate capture, deleting the rest. We had something like that in mail gateway support when I was there.
yes you are absilutly right. kill -15 will do the job better. I have copied that from internal without having a deeper look at it.(changed it now) Therefore i will award myself the "Useless use of kill -9 Award"
"Don't use kill -9.
It doesn't give the process a chance to cleanly:
1) shut down socket connections
2) clean up temp files
3) inform its children that it is going away
4) reset its terminal characteristics
and so on and so on and so on.
Generally, send 15, and wait a second or two, and if that doesn't work, send 2, and if that doesn't work, send 1. If that doesn't, REMOVE THE BINARY because the program is badly behaved!
Don't use kill -9. Don't bring out the combine harvester just to tidy up the flower pot."