Sophos Connect Losing Connections/Profiles

We have been experiencing this since DAY 1 with Sophos Connect on some old version. Now with 2.2.90 and 19.0.2 and 19.5.0 (the SFOS version makes no difference, it seems it's a client side issue) and as we have been using .PRO imports since the beginning - these still disappear.

Usually I find it's on the very first sign off / sign in.

When I set up a user with a .PRO and get them functioning and connected, we 'Sign Out' and then sign back in to Windows and try again. It's a total 50/50 shot whether that profile is still there or whether we have to import the .PRO. Again.

How is this still happening?

This is not sustainable to support hundreds or thousands of users.

Edit: The old SSL VPN had virtually no multi-factor implementation, so Sophos Connect is a MUST to even have a separate place for the OTP code to go. I have no idea how this is a reasonable solution the way it is. The old SSL VPN app at least had the profiles sitting as files in a directory so you knew what they were, they couldn't disappear, and you could even modify them with a text editor. Where is Sophos Connect storing these profiles? This should be something we can back up, verify, or even manually upload the configuration. But it requires 'hands on' every time, just to set up a .PRO. That's to add to the fact they have to log in TWICE to configure. Once it 'downloads the configuration' and the second time it 'logs in'.... but it doesn't 'Save' the user or password the first time. Why is it even a checkbox? I could go on and on but I'll stop. It just should never lose its config. Ever. It's been going on for years now.

Hi Paul,

Thank you for reaching out to Sophos Community.

Apologies for your experience. Can you share your case ID.

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 ?

Hello Paul,

For the Sophos Connect and adding a separate entry for OTP, you can follow this RR.

Are different users accessing the same device with different windows profiles (E.g, User1, User2, User3)?

Regards,

 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.