Hello:
I’ve been happily using thinlinc within just my LAN for quite some time. I finally need to configure things for use outside the LAN.
I’ve found myself utterly perplexed: From an external laptop, I can use SSH to access a server, but not Thinlinc. When I attempt to connect with Thinlinc, it even requests SSH password and seems to be connecting to the correct LAN IP… But then eventually just times out.
Thanks.
Also, should have posted the sshd log comments about this event:
Preformatted textMay 01 17:36:59 B550 sshd[198403]: Accepted publickey for serai from [ip] port 38399 ssh2: ECDSA SHA256:etc>
May 01 17:36:59 B550 sshd[198403]: pam_unix(sshd:session): session opened for user serai(uid=1000) by (uid=0)
May 01 17:36:59 B550 sshd[198403]: pam_env(sshd:session): deprecated reading of user environment enabled
May 01 17:37:00 B550 sshd[198403]: pam_unix(sshd:session): session closed for user serai
Hi @eumaios,
Please check the value of agent_hostname in the configuration file /opt/thinlinc/etc/conf.d/vsgagent.hconf. This will need to be set to something which resolves correctly both inside and outside your LAN, if you need to be able to connect from both networks.
There is more background to this here: Why does ThinLinc try to connect to a different IP address than the one specified?
Also, see the instructions here:
Let me know if this helps!
Hey:
This is really helpful, thanks–just the setting I was looking for.
I’m a bit perplexed, however, at how to achieve the condition you mention: i.e., setting agent_hostname in such a way that it “resolves correctly inside and outside [my] LAN.” I must use the FQDN of the public IP (say eumaios.net) to access my network (on some port for the particular device), yet the FQDN of any particular server on the LAN (owing to my pfSense DNS resolver) will always be something like box1.eumaios.net. It thus seems like an impossible condition. What am I missing?
Thank you!
Hi,
If you need to be able to connect from both LAN and Internet, then ideally the value of agent_hostname should resolve correctly from both locations. So for example, if agent_hostname is set to box1.eumaios.net, then this should resolve to your public IP from the Internet, and to your private IP from inside the LAN. This is known as a split-DNS configuration.
If this is not possible then it will still work if the hostname resolves to the public IP from both locations. However connections from the LAN will not be as efficient in this case, since traffic will be routed out through the Internet and back in via the public interface.
What you need to avoid is the situation where the hostname is unresolvable or resolves to a non-routable IP from the Internet.
I spent some time reading about split DNS and thinking about your reply here. If I understand everything properly, it is not possible for the servers, which I’m trying to access from the WAN, to have the same public and private IP. Suppose, again, my public IP is eumaios.net. The servers on the network at that address are thus: box1.eumaios.net, box2.eumaios.net, etc.
So it seems I will have to either plan on exiting from and returning to the LAN (when on the LAN), or just changing the agent_hostname when using from WAN.
Does that all seem right? Thanks, again, for your time and patience.
I think you have the right idea, but there is perhaps some confusion here:
This is a hostname, not an IP address. It will resolve to an IP address, and whether that IP address is public or private depends on the configuration of the DNS server you happen to be using at the time.
Same thing for box1.eumaios.net, box2.eumaios.net, etc. So a split DNS configuration would result in the same hostname resolving to one of two different IP addresses - a private one or a public one - depending on whether you are connecting from WAN or LAN.
Yes, right, I was abbreviating a bit. I use ddns-updater to update my current public IP to that the eumaios.net hostname through No-IP.
And then I have box1.eumaios.net, etc. all configured with pfSense’s DNS to resolve on my local LAN as such.
I was able to connect externally to each server on the LAN (with the plan to just edit agent_hostname). But, as a fairly new student of this stuff, were there a way to accomplish both, I’d want to keep studying the problem 
So one more question: I’m now wondering if I was thinking about the way split DNS works in the wrong way. I was thinking about it from within the LAN on pfSense. But would I rather have to configure it on the client outside the LAN?
I understand now. So not every server will have its own public IP, correct?
This is solvable, but not easily. Practically speaking, each ThinLinc server will need its own public IP address in order to be accessible from the Internet.
The good news is that since ThinLinc is a terminal server solution, you can run multiple sessions on the same server. So you may not need as many as you think.
Excellent! Though I will break my promise not to ask further questions. Could you point me to a section of the Thinlinc manual to study?
Appreciatively,
Eumaios
You could have a look here:
So I decided to take a different approach and use Wireguard, rather than switching the vsmagent.hconf constantly. It seemed this would by-passes the problem of internal vs external connections (since, if I use the tunnel, everything is “internal”). My sshd logs on the server I’m connecting to via Wireguard show that the publickey is being accepted; but then it also shows the client immediately disconnecting ("disconnected by user).
Any pointers here?
Thanks.
Are you using the native (i.e. installed) client, or the web browser client? What error message are you getting from the client side?
Is there any useful information in any of the following log files:
/var/log/vsmserver.log/var/log/vsmagent.log/var/opt/thinlinc/sessions/$USERNAME/last/xinit.logI’m using the native client, not web browser. The error is: ‘Connection to server “10.0.30.2” timed out. Check your settings.’ (that’s the correct server on my LAN)
Logs for the last connection attempt on the server (vsmserver.log) are:
2024-05-13 16:21:14 INFO vsmserver.session: User with uid 1000 requested a reconnection to 127.0.0.1:10
2024-05-13 16:21:14 INFO vsmserver: Verifying session 127.0.0.1:10 for privacy
2024-05-13 16:21:14 INFO vsmserver: Session 127.0.0.1:10 for privacy is alive and ready for reconnection
2024-05-13 16:24:03 INFO vsmserver.session: User with uid 1000 requested a reconnection to 127.0.0.1:10
2024-05-13 16:24:03 INFO vsmserver: Verifying session 127.0.0.1:10 for privacy
2024-05-13 16:24:03 INFO vsmserver: Session 127.0.0.1:10 for privacy is alive and ready for reconnection
Logs for the last connection attempt from the agent (vsmagent.log) are:
2024-05-13 16:31:58 DEBUG vsmagent: Handling method ‘get_load’ from (‘127.0.0.1’, 1023)
2024-05-13 16:32:38 DEBUG vsmagent: Handling method ‘get_load’ from (‘127.0.0.1’, 1023)
There is no $USERNAME/last/xinit.log on the agent. On the server, the logs for the last attempt are:
Mon May 13 16:08:58 2024
VNCSConnST: closing 127.0.0.1::34954: Clean disconnection
EncodeManager: Framebuffer updates: 25962
EncodeManager: Tight:
EncodeManager: Solid: 78.294 krects, 280.32 Mpixels
EncodeManager: 1.19467 MiB (1:895.837 ratio)
EncodeManager: Bitmap RLE: 49.311 krects, 15.9835 Mpixels
EncodeManager: 1.44469 MiB (1:42.5948 ratio)
EncodeManager: Indexed RLE: 204.021 krects, 280.857 Mpixels
EncodeManager: 43.754 MiB (1:24.5399 ratio)
EncodeManager: Tight (JPEG):
EncodeManager: Full Colour: 49.595 krects, 256.206 Mpixels
EncodeManager: 159.696 MiB (1:6.1236 ratio)
EncodeManager: Total: 381.221 krects, 833.366 Mpixels
EncodeManager: 206.089 MiB (1:15.4467 ratio)
Connections: closed: 127.0.0.1::34954
ComparingUpdateTracker: 4.21043 Gpixels in / 554.406 Mpixels out
ComparingUpdateTracker: (1:7.59448 ratio)
Thank you.
Please start the client from the command line with the -d5 flag, and check the contents of ~/.thinlinc/tlclient.log. If the issue isn’t apparent there then feel free to post the contents here.
OK, so this helps me understand what is possibly going wrong, but not sure what to do about it. It appears that tlclient is authenticating through the WG tunnel, but then trying to connect without the tunnel. This explains the log entry:
ssh[E]: ssh: connect to host 10.0.03.2 port 22: No route to host
ssh[E]: CONNECT ERROR: 113
Process 14377 exited with code 0
Process 14370 exited with code 255
Signal caught (2), exiting…
It seems that 10.0.30.2 IP should rather be the WG IP (not the local LAN IP).
What is agent_hostname set to? In this case, it would need to be set to the WG IP.
OK, finally got it. I was actually using Netbird, and just switched to simple Wireguard. Worked immediately. Appreciate your patience.
Great to hear if you need anything else don’t hesitate to ask.