Thread Info
  • State Suggested Answer
  • +1 person also asked this people also asked this
  • Replies 17 replies
  • Answers 1 answer
  • Subscribers 7 subscribers
  • Views 13068 views
  • Users 0 members are here
Options
Suggested

BUG - SSL/TLS Inspection Breaking ConnectWise/ScreenConnect

JTBrunnerACS

What feature is impacted?

ConnectWise/ScreenConnect remote admin sessions from behind Sophos XG firewall

What is the severity of the issue? (High, medium, low, minimal) 

HIGH

Summary of the issues:

When attempting to remote control a PC using the ScreenConnect service by ConnectWise (screenconnect.com) using a PC behind a Sophos XG firewall running SFOS v18 EAP2

the machine will fail to be able to negotiate a session with the remote PC via the ConnectWise Control client app. 

Observed behavior (What it did or didn’t do):

ConnectWise Control app would attempt to connect but retry repeatedly ending in failure.

Desired behavior (How is it expected to or should behave):

Should work as it did prior to v18 EAP2.

How do we reproduce it (Provide instructions to help us reproduce the behavior):

Obtain an account at screenconnect.com, add some PCs you wish to remote control, attempt to remote control from behind a Sophos XG, observe failure.

Other (Any other detail that we need to know about):

Turning SSL/TLS Inspection off temporarily will allow this to work 

Supporting logs, pcaps, etc.:

Will do some pcap for you but it won't be easy since you broke the pcap facility in EAP 2.

 

Here are some screen shots of Wireshark, PM with an e-mail address if you would like the actual pcap files... 

 

The problem lies in the response we get from ScreenConnect when SSL/TLS is enabled on the firewall. It appears that we lose 40 bytes somewhere in the translation...

 

This is interesting, I took a packet capture at the firewall to see what was going on between AWS and it...

Looks like the packets are being sent to the destination twice, once without NAT and once with?!?!?!?

Also interesting is the fact that the response from AWS isn't getting truncated here, only when it gets to the client behind the firewall.

 

 Note that the response packet at the firewall is still the proper size and contains all of the data...

Parents
  • 0

    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?

  • 0 in reply to JTBrunnerACS

    Hi , 

     

    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

Reply
  • 0 in reply to JTBrunnerACS

    Hi , 

     

    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

Children
Unfiltered HTML