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.

Alright Paul Kopalek  one more thing how many users log in on same Sophos connect client on the same machine, how many profiles are present and how often they connect and disconnect ?

 Vivek Jagad,

When this happens, it is virtually always a literally 100% brand new laptop that has never used any VPN before of any kind, with no applications on it except for Office and sometimes Sophos Endpoint.

 emmosophos Often it's a brand new laptop where this happens. Other times, it may be a laptop that someone else has used previously and they are now logging into it to use with Sophos Connect, importing their own .PRO and their own Windows profile. As I already stated - yes we are using .PRO files and that link you sent is inaccurate. The user does not simply get the ability to use an OTP only on the second login. It's the third login (the first one downloads the config - the second one does the first connection, at which point you can 'Save' the username and password, and the third login allows just the OTP). Also, that guide is missing a serious step - the VPN being set up by IP address will cause a Certificate error when adding the configuration, unless it's contacting the XG/XGS via hostname with a valid certificate. I would use the proper provisioning guide here https://docs.sophos.com/nsg/sophos-firewall/18.5/Help/en-us/webhelp/onlinehelp/AdministratorHelp/VPN/RemoteAccessVPN/VPNSConProvisioningFile/index.html#provisioning-file-2fa-settings and your YouTube video is much better https://youtu.be/FNtsEGAJGC4?t=380 (at about 06:20 you can see the certificate error). Your support also documents using the Appliance certificate but any User portal worth its salt should be outfitted with a valid public certificate (which is like $7/year anyhow) and set up using the FQDN. Pointing to the IP address of the connection leaves the user to only see the IP address to 'connect' to when they hit 'Sophos Connect' instead of 'vpn.example.com' which is just confusing to them. Furthermore, if it's not an FQDN, then any public IP / ISP changes will require reconfiguring every single (of dozens or hundreds) of VPN clients, which is hugely inefficient, considering you can't just push one file edit (such as the old .ovpn files on the old SSL VPN app) - each client must download and manually re-import the .PRO file because the .PRO file used an IP. So the .PRO should use an FQDN for almost any practical instance for anyone, it needs a valid certificate (a valid public one is like $7/year or something), and the .PRO file import requires multiple logins to get to 'Save' the credentials to get to the point of using only an OTP.

I'm not here to beta test software that is sold and deployed as final-version, enterprise-grade software. I call for support when I need it, but these cases are hard to nail down. You surely have thousands of users who experience this and who simply won't open a case for the same reason I'm not - making a user wait hours or days to just get their VPN connected (when they're only sick for one day or have COVID for two days) is simply not practical. They just keep re-importing the .PRO until it works, just like I do.

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.

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.