BUG - SSL/TLS Inspection Breaking ConnectWise/ScreenConnect

Unless "-i any" is a default then no, I'm not using that flag, it was a simple tcpdump "host xxx.xxx.xxx.xxx" -w capturefile.pcap command.

Hi JTBrunner,

If you don't define then yes it is default so that is why you are seeing the double packets. It's not easily shown in the wireshark but if you watch it inside the XG it will tell you it is arriving/exiting the ports, you can see it in the wireshark but you have to expose the mac addresses.

Emile

I was able to get https://amazonaws.com to go through the same firewall rule as the others by removing the * from the front of the entry for amazonaws.com in the Destination list of the Screenconnect firewall rule.

Unfortunately this is still very broken in EAP3, no Merry Christmas for us :(

Was hoping after this long they would have fixed this, unfortunately we will have to run with SSL/TLS disabled until this is resolved which is disappointing because XSTREAM is supposed to be the selling point of V18 and so far it has not worked well if at all since day 1. Maybe it will finally work in EAP4 next year?

Bump...

Hi JTBrunnerACS, 

What's happening is the TLS protocol being used is not recognized by our parser (or wireshark hence you see "continuation data" in your pcap rather than seeing full tls handshake). This gets blocked because by default, the box is configured to drop invalid traffic. This is to prevent someone from being able to circumvent web filtering by passing in invalid traffic. 

Here are the ways to workaround the issue with screenconnect:

1. create a firewall rule with a fqdn host for "*.screenconnect.com" in the destination network field and ensure web policy is none, app policy is none, malware scanning is unchecked and ATP is disabled globally. Only then will the problematic parser be bypassed.

2. create a firewall rule with a fqdn host for "*.screenconnect.com" in the destination network field and choose "allow all" web policy and check "Use web proxy instead of DPI engine". 

3. enable relay_invalid_http_traffic via cish by following the instructions described here: https://community.sophos.com/kb/en-us/123730. This is the least recommended approach.

Please let me know once you have had a chance to try the workarounds. 

Cheers,

Paul

Looks like Option 2 did the trick, I already had a firewall rule created for Screenconnect but it was setup more like option 1. I changed it to the Allow All policy and turned on Web Proxy and then turned SSL/TLS Inspection back on. So far Screenconnect seems to be working.