Thread Info
  • State Suggested Answer
  • +1 person also asked this people also asked this
  • Replies 17 replies
  • Answers 1 answer
  • Subscribers 7 subscribers
  • Views 13056 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 in reply to JTBrunnerACS

    Here is what I'm seeing in the log viewer...

     

    2019-11-26 10:11:08SSL/TLS inspectionmessageid="19006" log_type="SSL" log_component="SSL" log_subtype="Error" severity="Information" user="jbrunner@alliedcontrol.com" src_ip="10.40.10.103" bytes_sent="1464" bytes_received="219" dst_ip="52.6.130.216" user_group="OU=ACS Users,OU=MyBusiness,DC=alliedcontrol,DC=com" src_country="R1" dst_country="USA" src_port="56901" dst_port="443" app_name="" app_id="0" category="Information Technology" category_id="29" con_id="0" rule_id="1" profile_id="1" rule_name="Exclusions by website or category" profile_name="Maximum compatibility" bitmask="" key_type="KEY_TYPE__UNKNOWN" fingerprint="" resumed="0" cert_chain_served="TRUE" cipher_suite="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" sni="alliedcontrol.screenconnect.com" tls_version="TLS1.2" reason="Dropped due to TLS engine error" exception="av,https,validation,policy,sandstorm" message=""

    Strange it would be even scanning it with so many rules in place saying not to touch this traffic, yet. it is.

  • 0 in reply to JTBrunnerACS

    Thanks JT, we are looking into it.

     

    By chance, do you have anything in the Web Filter log?

    One possibility is that the XG is trying to display a block page or SSO authentication.  That is one reason that it may try to decrypt traffic even if everything says not to.

Reply Children
  • 0 in reply to Michael Dunn

    Nothing at all in the Web Filter log, there is a firewall rule that applies to only Screenconnect and it has no filtering turned on at all. 

    I did a few policy tests, here are the results...

    Only odd thing I noticed was this...

    The firewall rule and URL group contain amazonaws.com but if I test policy directly to that URL with no subdomain I get the result above. Could this be the reason for the double destinations in the pcap file captured on the firewall?

    Here is a list of our rules, as you can see Screenconnect is on top above the rule that amazonaws.com is filtered by...

  • 0 in reply to JTBrunnerACS

    Hello JTBrunner,

    Sorry to interject again, if you are doing the "-i any" the XG will double cap for the entry and the exit packet. For instance, see my Port 443 cap below:

    SFVH_SO01_SFOS 17.5.9 MR-9# tcpdump -nni any port 443
    tcpdump: Starting Packet Dump
    16:33:06.845849 Port2, IN: IP 52.97.146.146.443 > 80.0.80.42.60006: Flags [P.], ack 1453913243, win 2049, length 43
    16:33:06.845937 RedBridge, OUT: IP 52.97.146.146.443 > 172.16.1.115.60006: Flags [P.], ack 1453913243, win 2049, length 43
    16:33:06.845945 Port1, OUT: IP 52.97.146.146.443 > 172.16.1.115.60006: Flags [P.], ack 1, win 2049, length 43
    16:33:06.888945 Port1, IN: IP 172.16.1.115.60006 > 52.97.146.146.443: Flags [.], ack 43, win 1025, length 0
    16:33:06.888945 RedBridge, IN: IP 172.16.1.115.60006 > 52.97.146.146.443: Flags [.], ack 43, win 1025, length 0
    16:33:06.889001 Port2, OUT: IP 80.0.80.42.60006 > 52.97.146.146.443: Flags [.], ack 43, win 1025, length 0

    I'm having a triple capture because I have a bridge.

    Emile

  • 0 in reply to Emile Belcourt

    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.

  • 0 in reply to JTBrunnerACS

    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

  • 0 in reply to JTBrunnerACS

    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.

Unfiltered HTML