This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Safeguard Enterprise server over Internet not via VPN

Having trouble when syncing with SafeGuard when not connecting via VPN, after looking at this thread: 

https://community.sophos.com/encryption/f/discussion/104413/clients-connect-to-safeguard-enterprise-server-over-internet

We have this setup, but get this error when running SGNCSCC.exe tool.



This thread was automatically locked due to age.
  • One of the reasons my secondary is in the DMZ and has a public cert! I'm afraid your options are...config file....or install the certs manually. How many WG PC's are there - it that the 200 plus figure or is that the whole estate?

  • Probably the same if not more, however we will hopefully be moving away from workgroups in the future, so with this in mind it's not that urgent, but can I ask what issues we will stumble across if we leave it? I presume from a support side we can still recover Bitlocker codes via the helpdesk etc?

  • If there's a primary server that still works - no real issues at all. Your secondary is there purely as a failover to the primary should that become unavailable. Yes - as long as the primary remains up and there's a server to communicate with every X minutes (what's ever set as your policy). I would personally resolve it - but appreciate it's hassle. 

  • Hi Michael

    Thanks for all the advice you've given Dan P already, much appreciated.

    We had this secondary server set up to allow all our Citrix users' computers to sync with SGS. These computers are remote (no direct connection to our network, no VPN, etc) and they are workgroup only.

    What that in mind I just have a couple of follow-up questions I wonder if you could clarify please?

    1) Our secondary server is in the DMZ (or port-forwarded, strictly speaking). Given what you said above, about keeping your server in a DMZ and using a public cert, if we purchased a public cert for this server, to replace the one from our CA, would that allow these remote workgroup clients to start synchronising again?

    2) If we don't resolve this, what's the implication for these clients? Is it basically just that they won't be able to sync any new policies or changes to existing ones? We don't really ever change the policies that we created at the beginning, so we could probably live with that until we eventually move away from Citrix.

    many thanks

    Dan W

  • Hi other Dan!

    1 - In theory this should work. Assuming the public CA AND the supporting intermediaries are publicly accessible so the chain doesnt break down. Is this secondary server ONLY for the workgroup devices, or do the domain devices use this as their secondary too? Do the workgroup devices ever use the primary?

    2 - If the clients fail to report back to the server then they'll fail to report back any BL changes. This could mean the server does not have a copy of the current recovery key if the key rotates after use. It also means no policies as you pointed out. Something you could possibly live with IF you're running the very latest client and backend. If you're not and you need to change the backend or client - You will have to assume the server doesn't change the behaviour of the client. This has happened before where an update for me personally caused OneDrive to really mess up. It turned out the File Encryption policy had to be modified - even though I wasnt using it. 

    I'm not sure of your own timeline but you're probably aware that SSG has been declared EOL now and won't be any new versions as such. How much effort you want to put into this, combined with a planned move away from Citrix I don't know. As I said, I would resolve this mainly for rhe issue of outdated RK's on the server. It's only going to take one user to kick off if their drive needs a RK and helpdesk can't produce one (or at least a current one that works!)

  • Hi Michael

    Thanks for the reply.

    In answer to your question, from memory all endpoints are configured to try the primary first, and then the secondary if they can't reach the primary. So although the workgroup devices will attempt to contact the primary first, they'll never find it and will always fail over to the secondary. This was how it was set up by our Sophos partner a couple of years ago.

    Dan