With WebEx type traffic it needs to be exempt from the SSL scanner. You have attempted to do this with the bypass for *.webex.com... but in a transparent environment, this would be seen as an IP because its secure. The Web Gateway would not see the GET request like it does with HTTP traffic. So... you need to bypass based on the IP in certain situations.
For this, WebEx publishes lists of their ranges:
Citrix does the same thing:
I have created a rule you can import which references these ranges. See attached. You would want to place this ruleset towards the top.
Hope this helps in understanding the problem better.
On your last comment, it is possible to do this on your cisco device using ACLs essentially exempting it from WCCP (but it would be based on IP). There isnt currently a way for the Web Gateway to send the traffic back where it came from, the best solution to that would be tunneling or encapulating the traffic somehow.
WebEx - Workarounds.xml 5.3 K
Doh, totally forgot about that! I applied the IP range and it works like a charm.
Yes, we could definately block certain ranges from going to the proxy via ACL on our router, and I've done that before at other places. The rub is that it is nice to be able to exempt certain IP's from proxying without having to go through another IT group
Great forum as usual. Interested to see what the latest version of the gateway brings!
Would it be safe to assume that LiveMeeting is another vendor that would need to be addressed in a simular manner?
You know, the question I have about all this bypassing is what if a file is transferred over webex or gotomeeting. Bypassing everything leaves us wide open to what we are trying to protect against. Is this really the best way to handle the traffic?
The traffic within these SSL tunnels are not HTTP traffic, instead they are propietary traffic designed by the webex and citrix, to the Web Gateway or any other device attempting to interpret this data, it will appear as binary garbage. I'm not sure if LiveMeeting is the same, based on J's link, it looks like they simply need to bypass authentication, so it very well could be some sort of HTTP traffic. But.. often the designers of the software also hardcode the trusted CA, so SSL scanning will not allow it to be scanned (and have the software work).
Hope this helps in understanding the issue.
My experience with Live Meeting is that is follows the same behaviors as Citrix and WebEx. I am dealing with this in the following manner:
I created a top level ruleset where the criteria is URL.Destination.IP is in range list WebExRanges (thank you jon!). I added the Live Meeting and Citrix blocks to this list. Then set the Authentication to RawCredential (because I have noticed authentication failures). This allows us to also add additional rules such as Anti-Malware and the like. Finally, I stop the cycle as to bypass the SSL scanner ruleset and the NTLM Authenticaiton ruleset.
Using this solution, users are able to get sound in thier meeting with these conferenece services.
All of our desktops/laptops are protected with a antivirus client so there is a line of defense there as well.
If anyone has a better plan or suggestions, I would be happy to hear about it.