SystoLOCK Clients have the ability to discover SystoLOCK servers within the network. They do by issuing DNS queries against a local DNS server.
These queries contain the name of the domain, since the workstations are, normally, domain-joined and that domain name is known to them. For example, if the name of the domain is
company.local, the Client will query the DNS for the SRV record with the name
_systolock._https.company.local. The resulting set of servers will be then talked to in a round-robin fashion.
For Clients outside the network, like SystoLOCK Companion and VPN Client, there is often, no way to determine the domain name you want to connect to. Also, a domain name like
company.local cannot be published to the internet.
You can, however, hint the Client with either a synthetic domain name or with a UPN suffix of your users.
Let's say, the UPN suffix inside your
company.local domain is, actually,
company123.com. Then you can forward the TCP port 21572 from your internet-facing server, known to the world as
gateway.company123.com to your internal SystoLOCK Server and publish a public DNS record in the flowing way:
_systolock._https.company123.com. IN SRV 0 100 21572 gateway.company123.com. gateway.company123.com. IN A <some-ip-address>
This way, you can instruct your Clients to connect to the correct SystoLOCK instance just by properly formatting the user name. For the above example, there are three possibilities:
All these combinations will end up in looking for SystoLOCK Endpoints within the outside domain
company123.com, even though the internal name of the domain is
If you run a split-DNS configuration and the name of SystoLOCK server is different as seen from inside and outside the perimeter, you'd need to bind a SAN certificate to SystoLOCK service that bears all possible names for it.
Never let a perimeter gateway (like Sophos Firewall) alter the TLS certificate for the connections to SystoLOCK server, otherwise SystoLOCK Companion, would not be able to connect to the server.