There are a few requirements to provide access to a ThinLinc installation behind a NAT gateway using ThinLinc clients. We will first describe how the native ThinLinc client connects to an server. We will then move on to a few common problems and how to solve them.
When a ThinLinc client connects to a ThinLinc server, it will first contact the ThinLinc master server which will redirect the client to an ThinLinc agent server where the session for the user is located. The client disconnects from the master and then connects to the address for the agent to establish a connection to the session.
The address reported to the client from the master server, is per default the IP address of the agent server. The reason for this is that a single ThinLinc server installation should work out-of-the-box without any network / DNS configuration.
Let us define an example network setup that we use as reference throught this guide. We have two networks, outside: 10.47.1.0/24 and local: 192.168.1.0/24 which is separated with a NAT gateway. We have two ThinLinc servers tl01: 192.168.1.101 and tl02: 192.268.1.102. The two ThinLinc servers are installed on the local network which we want to access from the outside.
The first problem to solve is to give IP access to each ThinLinc server on the local network that are reachable from the outside. This is done by adding static NAT rules, also known as port forwarding, from allocated addresses on the outside network to the ThinLinc server(s) on the local network. As the native client and Web Access communicates with the servers using SSH and HTTPS respectivly, only two rules per ThinLinc server are required. For our example that would be following two static NAT rules;
10.47.4.101:22 -> 192.168.1.101:22
10.47.4.101:300 -> 192.168.1.101:300
10.47.4.102:22 -> 192.168.1.102:22
10.47.4.102:300 -> 192.168.1.102:300
The second problem is to handle the fact that the address for an agent reported back from the master to the client upon initial connection needs to be either an address on outside or local network dependent on which network the client resides on.
This problem is solved by using DNS names instead of IP addresses for each agent server which resolve to different IP addresses dependent of from where the resolve is performed. Eg, a resolve of the hostname tl01.domain.tld when the client is on an outside network, resolves to 10.47.4.101 or 192.168.1.100 if client is on the local network