I’m currently working to set up access to a remote thinlinc server from my MacBook, using the ThinLinc client from behind our company’s firewall.
The client works well when connecting from home (outside the company’s firewall). However, when attempting to connect from within the company network (either onsite or over VPN), the GUI client hangs at the message: “Connecting to server thinlinc...”
In contrast, I’m able to connect via command-line SSH using a proxy tunnel (via corkscrew), and receive the following response:
THINLINC-LOGIN: HELLO 4.17.0
THINLINC-LOGIN: CONNECTED MASTER
This suggests that the basic SSH handshake succeeds, but the GUI client is unable to complete the full connection. I’ve tried various configurations using .ssh/config, .thinlinc/tlclient.conf, and .thinlinc/client.conf, but none have resolved the issue.
Is there a known workaround to enable the ThinLinc GUI client to function behind a restrictive firewall? Would a firewall exemption be necessary in this case to allow outbound SSH access (port 22) to the remote server? Any guidance or suggestions would be greatly appreciated.
Probably what’s happening is that the second connection is failing. If this is the case, you’ll be able to see it in the client logfile.
The ThinLinc client always connects twice; once to the master, and then again to the agent. This is true even if the master and agent are on the same machine. The second connection (i.e. to the agent) happens via whatever the parameter /vsmagent/agent_hostname has been configured as (or the IP of the primary interface if this parameter has been left blank). If you’re connecting via a proxy, then then you’ll need to ensure this parameter has been set appropriately. Hope that helps.
Thank you very much for your quick response! Your explanation helped me better understand the two-step connection process (first to the master and then to the agent).
I checked the ThinLinc client log files for both a successful connection (from home) and a failed one (from within the company firewall). From home, both SSH connections succeed, first to the master and then to the agent, and the session launches as expected.
In the case of failed connection, it seems the problem occurs even before the second connection. The GUI client times out during the initial SSH handshake to the master, with the log showing:
ssh[E]: kex_exchange_identification: read: Operation timed out
So the second connection to the agent is never initiated. This leads me to believe the issue is firewall-related, possibly blocking outbound SSH entirely, rather than misrouting the agent connection.
For comparison, when I connect from the command line using a proxy tunnel (via corkscrew), the connection succeeds with response of:
THINLINC-LOGIN: HELLO 4.17.0
THINLINC-LOGIN: CONNECTED MASTER
This suggests that the firewall allows a manually tunneled SSH connection via proxy, but the GUI client, likely due to how it handles SSH internally or attempts multiple simultaneous streams, fails at the very first step.
Given that, it seems a firewall exemption for outbound SSH access on port 22 is needed in order for the ThinLinc GUI client to work from within the firewall.
Would you agree, or is there another workaround you’d recommend?