Many SSL VPN solutions, destinations which use client certificate authentication, applications which tunnel non-HTTP traffic via SSL and applications which require a non-intercepted connection cannot be sent through the SSL Scanner. In those cases, you need to put a bypass rule into place.
Something like: URL.Destination.IP equals 188.8.131.52, Action = Stop Cycle in your rule set before you enter the SSL Scanner rule set.
What btlyric suggested is still a viable test to see if it is filtering related or not. Alternativley you could try a bypass rule in the MWG rules for the client IP (of the VPN device in your network).
If this works then it indicates a policy rule that could be blocking something for one reason or another. If it does not work, then I would wonder what a packet capture looks like (dont post it here).
Shot in the dark, but could the VPN be adding to the packet size and possibly be causing it to be, to big to pass over WCCP?
I have seen WCCP headers added to the TCP packet which were then dropped by the cisco device. This caused the packet size to be over 1500 in some cases.
If you are seeing a handshake I would doubt this is the case because that means packets are getting through.
We're not using SSL Scanner due to concerns about breaking PII and HIPPA content. About all we do is check category of requests, reputation of site, and scan for maleware.
You may already know this, but I thought it was worth clarifying that if you aren't enabling the SSL Scanner you won't be able to detect any malware that's downloaded from sites that are using https. This opens a pretty big hole for malicious file attachments on webmail sites (if you permit access to these) that are often downloaded over https.
Unfortunately, since this is our guest network any client on there might be using the Cisco VPN. We do have a ticket open with Cisco, I sent them a packet capture and they see something hinky in there. We've got some more troubleshooting efforts planned. I may take you up on your offer to read through the traces we have.
Some troubleshooting suggestions:
- put in a rule at the top of the rule set that does a Stop Cycle for the specific destination. port 443 that's being problematic and test
- put in a rule at the top of the rule set that does a Stop Cycle for traffic to destination port 443 from your guest network and test
You stated that the VPN connection works if it is made on a network for which WGA is not in the path. Are there any differences in egress filtering on your firewall whether it is through allowed ports or protocol compliance inspection, for your network that has WGA versus the one that doesn't?
The Cisco AnyConnect client (and destination VPN appliance) can be configured to use either SSL/TLS or IPsec for the VPN tunnel. For SSL it can be configured to use DTLS which is UDP on port 443 instead of TCP. You stated that you are using WCCP from the WGA to the routers to have http/s traffic (ports 80/443) sent to the WGA. Is it possible that you are routing port 443 for both TCP and UDP instead of just TCP? What's the error message that the Cisco AnyConnect client is producing?
It's possible that they are running their VPN service on non standard ports. What does the network packet capture show? If for testing you completely whitelist that client IP address in web gateway (stop cycle for all) can they connect or does it still fail?
I worked with Cisco and the partner company last week. Turned on traces and what monitors we could get going. We were able to get the web client working through the WCCP WGA. I don't have permission to load their client version on my PC, and the partner's employee who is usually resident at our offices is out of the office for a few weeks. Suspicion is that the problem is related to the TCP/UDP options in the client. It's possible the client is attempted to negotiate a IPsec tunnel that would not go through the gateway, then falling back to SSL/TLS over TCP. Someone's firewall is having a problem with the change in route and seeing an asymetric flow. This is causing the conenction to be dropped.
Final result, when the eemployee returns, if his AnyConenct client still does not work he will get to use the web client as we know this works.
Thanks for the suggestions and thought starters.