Was this question ever answered, or does someone have a good way to troubleshoot these issue. We are testing WG7 and run into issues with all webex type site.
I had this issue with gotomypc.com. I finally open a ticket for support and had to provide them a feedback file and tcpdump of failure. There answer was to whitelist the ip? Seemed to work, although we took the approach of placing those machines on a public drop to protect the network from remote access.Message was edited by: imtrying on 12/14/11 1:35:20 PM CST
The sites timing out would be the biggest issue. There are so many flavors of webex these days that adding them be source IP would be time consuming.
Here is what I did. Added a rule under "Authenticate and Authorize" called "Auth Bypass". Rule Criteria "URL.Host" matches in list "Auth Bypass URL Hosts".
Then added *gotoassist.com, *gotomeeting.com, *.webex.com.
This seems to work.
I am also thinking about adding these sites to the list "Response URL Host Without Path Whitelist" under "Handle Special Sites".
When using Web Gateway's HTTPS proxy with SSL scanning enabled, the client cannot establish a connection with GoToMeeting.com, GoToAssist.com, and other CitrixOnline sites. Also, the test client available for CitrixOnline customers sometimes fails. Bypassing the SSL scanner for CitrixOnline.com, GoToAssist.com, and/or GoToMeeting.com is not an effective solution.
please follow the KB, i had same issue with my Web gateway 7.0, its working fine now after doing the changes mentioned in the KB.
We have the same issue as the user: imtrying. Is there a way to get these sites to work and block the remote access feature? During the WG7 training, the trainer mentioned that the only way he could think of a solution for this was a reverse engineer of the traffic and block the remote access connection attempt at a byte level.
Does McAfee have a ruleset on this and can a solution be provided? Multiple large organization could benefit from this... The KB article mentioned by musaleem includes a bypass/exception in both solution.
You could use the rules found in the links below, then enable SSL scanning for them, that is the functionality in MWG that breaks the remote access part (because its not actually HTTP within the SSL tunnel).
These rulesets allow it, but the same concept could be done to enable ssl scanning.