new XG installs are causing ScreenConnect 'last connected' timer resets even though NO security services are enabled.

Question

I have now set up two firewalls for two different clients who also use our screenconnect software on their machines for us to remotely connect for repair, diagnostics, etc. The screenconnect software on the client machine will regularly poll back to the screenconnect server (located in my office) to let the server know that it is available and online. This shows as a 'time connected' counter in the screenconnect dashboard. This has always been very stable, and has not been blocked or otherwise interfered with by any other firewall or security appliance. All clients that do not have sophos firewalls do not exhibit this behavior. However, the two XG (115 and 210) firewalls that I have installed in the last two days are causing that counter to reset every 5 minutes (I can see the activity in the screenconnect logs). Both firewalls are in gateway mode, directly connected to the ISP and have NO security services enabled yet. No AV, no IPS, No web filter...nothing. Just the default rule in the firewall that is put in place during the initial configuration wizard. 
 FYI, the client is set to relay out to the screenconnect server on port 80 and 443, so I don't understand why that would get reset every 5 minutes.

Sam Segura · Accepted Answer

Light at the end of the tunnel... hopefully. 
 Here's just an idea of what might be an optional solution. Use an optional port (other than default 80/443 8040/8041). You will have to reconfigure your SC relay server to use a different port (or port forward inbound traffic for your SC Server). 
 1) Change the port on the SC server 
 2) Add/change rules on the server's firewall to forward both old port+forward to new port / forward the ports. 
 3) On the SC Host screen website, do a "Re-install" on a client that sits behind one of your deployed Sophos firewalls. Just test one. Make sure it has Remote Desktop enabled, just in case you need to get back into that machine from another one on site to revert back to a previous settings. 
 
 Change ports for ScreenConnect On-Premise 
 https://help.screenconnect.com/index.php?title=Change_ports_for_ScreenConnect_On-Premise 
 If you need to change the entire URL for relay:, Change relay address for ScreenConnect On-Premise access sessions 
 https://help.screenconnect.com/Changing_the_relay_address_for_unattended_access_clients 
 On the SC server, the web.config file is found C:\Program Files (x86)\ScreenConnect 
 
 You would then run the "Re-install" from the host screen. Here's a forum that might provide some insight on changing all the host clients to look for the new relay server port 
 Check out the last post from RazorbaQ for a skinny on the process. 
 http://forum.screenconnect.com/yaf_postst727_Quick-Relay-Port-URL-Changer.aspx

sachingurung · Answer

Hi Paul, 
 Check #1 in my guide here . Capture drops on the destination/ source IP and port. If you do not see any drops, take a pcap and verify who generates the RESET packet. 
 Thanks

Paul Schwegler · Answer

I couldn't get those commands to work, my console wont open, and I can't reboot the FW right now...Anyway, I know that micro app discovery is OFF in all of the app filter policies, and has been since the beginning. 
 That being said, this issue is SOLVED! After changing the listening ports on the screenconnect server, adding those to the forwarded ports for outside traffic (see above post for details), the server started slowly updating all of the external clients to the new 6.1 version, with the updated relay port. After 24 hours, all clients that are attached have an updated version of the software, and the counters are all working correctly, even if the distant network also has a sophos. 
 In the end the solution is a work-around. For some reason, the XG is still 'scanning' or manipulating traffic on the common web ports of 80 and 443 (and possibly others) even when ALL filtering is disabled on the firewall rules. 
 SOPHOS, PLEASE GIVE US THE ABILITY TO TRULY TURN OFF ALL TRAFFIC MANIPULATION!

Adam Hiramiya · Answer

So it turns out even when you have all security settings off, indeed the XG is still proxying connections that go via certain ports - this means any connection going via the Web Proxy Configuration 's Allowed Destination Ports found under Protect>Web>Advanced and shown here: 
 
 While it may not necessarily be doing anything to the traffic (such as scanning) the connection is still proxied. Using conntrack on the device command line showed two active flows as part of the connection: 
 
 The first flow shows the client device (10.5.11.3) attempting to communicate with our SC server, but the reply-src has been adjusted to the IP of the XG (10.5.11.250) In the second flow, the XG itself is there as orig-src, with the correct reply-src and reply-dst. This is the proxied connection that actually leaves the network. 
 The solution to this is to add your SC server as an exception to the Web Proxying - this is under Protect>Web>Exceptions: 
 
 And after configuring this exception, waiting 5 minutes for the session to reconnect again, there is only one flow in conntrack: 
 
 This time, the orig-dst and reply-src are both the IP of the SC server, meaning the XG is not proxying the connection. 
 And shown here in the SC timeline, the connection resetting every 5 minutes before adding the exception, and then 28 minutes where it was fine (until I closed the session)

It should also be noted, this XG does have micro-app discovery disabled, as that was causing plenty of other random little problems which all went away once disabled. 
 Hope this helps everyone!

RyanDougherty · Answer

I know this is an XG version thread (and a few months old) but I have an SG210 UTM and I updated 6 versions to 9.414-2 at once on July 4th. That is when I noticed this weird issue with my screenconnect clients that were behind the Sophos never staying connected to the connectwise-hosted service for more than a few minutes. After investigating further, I found that it was exactly 5 minutes and the client would disconnect and reconnect. 
 I was going to start with an exception but I ended up going with the transparent mode skiplist first. I added a new DNS group with servers.screenconnect.com as the host and it resolved all of their IPs (76 as of today). Once I applied the changes, I have been connected for over 25 minutes now.