Sophos Connect Losing Connections/Profiles

Hello Paul Kopalek ,

Thank you for reaching out to the community, the profile are usually stored in c:\program files (x86)\Sophos\Connect\Protected folder
Are you using any AV endpoint which might be detecting the profiles malicious for some reason and deleting it ?

Vivek,

Thanks for that but that appears to be some kind of encrypted file which holds multiple profiles and data in it. But now I will look for that file (if it's there) when this "issue" happens and try to observe whether it disappears.

We use Sophos Endpoint and (if we are installing that last) just Windows Defender. There are no AV alerts, detections, or events whatsoever in Defender or Sophos Endpoint when this happens.

I'm not the first one to start a post about this -  Sophos Connect client looses profile when changing network 

I also am already following the advice in that thread.

Erick Jan This is difficult to create a case for, because the time I have to spend on getting one individual user set up on the VPN is a "it needs to get done this morning" thing. There's not time to mess around, open a case, wait for a call back, troubleshoot it, find nothing wrong (because usually after one sign off / sign on, and setting up a second time, it "just works"), and then wait for another case. It's a bit of a ghost. I'll have to try to create replication steps reliable enough to demonstrate it, perhaps on a separate device. This is just a hard case to create because setting up an individual user is a time-sensitive deal and messing around creating a case adds hours and days to something that is "fixed" by adding the profile a second time (usually).

Hi Paul, We are still having this issue. Our only option was to resort to installing OpenVPN Connect client.

Far from ideal, and a really poor showing on Sophos' part that they can't fix their own product. We too use Sophos Endpoint AV. The last guidance we got was to update the SFOS to 19.5 and try again. We've not long completed that, and are planning a new test sample to trial the 'latest' version of SophosConnect, but on hearing your experiences of it still doing this now, and always, perhaps this will be a waste of time.

Hi Paul, We are still having this issue. Our only option was to resort to installing OpenVPN Connect client.

Far from ideal, and a really poor showing on Sophos' part that they can't fix their own product. We too use Sophos Endpoint AV. The last guidance we got was to update the SFOS to 19.5 and try again. We've not long completed that, and are planning a new test sample to trial the 'latest' version of SophosConnect, but on hearing your experiences of it still doing this now, and always, perhaps this will be a waste of time.

ptho said:

update the SFOS to 19.5 and try again

everyday business.. :-/

I remembered that post also  Sophos Connect client looses profile when changing network - probably there should be something to recreate the issue.

ptho said:

This is especially problematic as the users will then have to come back on site for the policy to download, as the User Portal is not available to them over the WAN.

Whilst we could enable the User Portal on the WAN, it exposes the Firewall to abuse. So this is a step we want to avoid.

Does that work for you? We notice from time to time - we don't know when - the clients that were set up with .pro file out of a sudden have to re-download the config from the user portal: the user connects to VPN and you immediately see by the captcha filed, that it needs to re-download the config from the userportal. Of course, the user is on WAN zone then.

We always find ourselves in between the usability and the recommendation to deny access to userportal from WAN.

I'll just say that we use two different solutions to this based on the customer.

1- Dynamic DNS (this isn't perfect) either each endpoint has dynamic DNS set up to begin with, and there's an ACL exception for User Portal over WAN for this, OR for one client, dynamic DNS update link is sent to them via email like so https://www.namecheap.com/support/knowledgebase/article.aspx/29/11/how-to-dynamically-update-the-hosts-ip-with-an-http-request/ (there are others but namecheap offers one easy solution to click an HTTP link and updated DNS) (sent via a secure expiring link in sharepoint) and then they can update config

2 - Once someone needs their config re-done or a new deployment, we go in and check the box for 'User Portal' on the WAN until that person is configured.

Huge caveat that is still not fixed: If your SSL VPN uses port 443 and your User Portal uses 443, you literally can't disable the user portal even if the box is unchecked. Disabling it is two steps. One step is to uncheck the box, and the other step is to go into the next tab and change the port (admin and user settings > user portal HTTPS port) change to 1111 or similar.

We refused to open the User Portal up over the WAN because even with MFA, this isn't perfect; if someone's credentials are known to an attacker, and the victim had not/yet setup MFA on the User Portal, then an attacker can log in to the User Portal with just User/Pass and setup MFA with their own OTP/device.

If the User Portal availability on the WAN had the caveat that it's only available if the user already has MFA enabled/enrolled, we would be more comfortable allowing this.

Precisely the reason that we only allow it during certain time windows, and even for case #2, we sometimes just ask them to go to whatismyip.com and then make the ACL exception for that IP for the user portal. But again unfortunately, this all falls apart if your SSL VPN port is 443. You literally can't disable its access from the WAN and it's a huge vulnerability for Sophos XG / XGS.

Not really. With the gateway's vanishing, they still need to import the .PRO file again. So we tell people to come on site so that they a) get the .PRO file and b) can connect to the Gateway's to get the policies. We don't inform the user that A is possible when off-network because they'd still need to be local to get the policies. Otherwise it causes more confusion. As below, we refuse to open the User Portal on the WAN. For those problematic users, they're given OpenVPN Connect client. So far, no issues with that. It's especially odd because Sophos Connect seems to be a branded version of OpenVPN Connect. Uses OpenVPN technology. And yet their own product is broken. Sadly you can't automate configuration with OpenVPN Connect like you can with Sophos Connect, but seeing as that's bugged for a considerable portion of users, you could say that you can't do so with Sophos Connect either.