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 ?

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.

Hello Paul,

Thank you for the extended feedback; the link I shared was related only to your comment, "so Sophos Connect is a MUST to even have a separate place for the OTP code to go."

I will pass your feedback for the rest to PM.

Regards,