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:
someuser@company123.com
company123.com\someuser
company123.com\someuser@company123.com
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 company.local.
If you run a split-DNS configuration and the name of SystoLOCK server is different as seen from inside and outside the perimeter, you might (depending on your toplolgy) need to bind a SAN certificate to SystoLOCK service that bears all possible names for it.