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

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.

  • In reply to Paul Schwegler:

    Just out of curiosity, does turning off micro app discovery from the console help this issue:

    console > system application_classification microapp-discovery off

    verify by:

    console > system application_classification microapp-discovery show

    turn back on after testing by:

    console > system application_classification microapp-discovery on

     

  • In reply to Greg CT:

    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!

  • In reply to Paul Schwegler:

    It is well known that turning off the micro app discovery in the app filter policies does not really fix the issues.  You need to turn off micro app discovery on the console to really test.  If switching the ports helped the issues, it does point to micro app discovery to me.  I agree with you that this is a major issue and one  that Sophos has said they are addressing in v17.  Let's hope it gets fixed.

  • In reply to Paul Schwegler:

    Glad to hear.  For those who have ScreenConnect on-premise and who's host clients are behind a Sophos XG firewall, this is a solution. 

     

    Note: this does not solve the issue for those who have ScreenConnect cloud accounts.  

  • In reply to Paul Schwegler:

    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!

  • In reply to Adam Hiramiya:

    Thank you! I will give this a shot once I have a chance to do the changes. 

  • In reply to Sam Segura:

    We've had this issue since v16. In v15, this wasn't an issue.

    Exception fixes it.

  • 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.