ThinLinc access via Cloudflare tunnels

I am exploring a new option to expose a ThinLinc server on Ubuntu using the Cloudflare tunnel offering instead of local Firewall holes. The concept is done by running a Cloudflare connector endpoint inside your protected LAN where this connects and proxies the connections thru to the Cloudflare tunnel. I am attempting this as NGINX is no longer required and and SSL Certs needed by the client are provided by the cloudflare side, even if you have a locally signed SSL Cert this still works with a setting change on the tunnel configuration

So far I setup the tunnel on Cloudflare using [ https://<local-ip:300 ] ( Cloudflare tunnel lingo) on the inside. The connection uses a valid sub-domain to link this together.

When testing I immediately get into the web Interface of the ThinLinc server where I can put in my username password and then the connection no longer progresses. I am assuming the ThinLinc server can sense a proxy during the conversation so discontinues this connection?

Is there any configuration on the ThinLinc server where I can tell the ThinLinc server the IP of my local Cloudflare connector ( proxy) IP to allow the connection to continue?

I have seen the article linked to Nginx Proxy rewrites and that works within Nginx

thanks

I don’t have any experience using ThinLinc over Cloudfare tunnels unfortunately, but it may be that the redirect isn’t working. What is the value of the agent_hostname parameter in /opt/thinlinc/etc/conf.d/vsmagent.hconf on your ThinLinc server? This would need to be set to “localhost” so that the browser redirects to your client machine.

There may be other issues connecting over such a tunnel, as mentioned I’m not familiar with the solution. But let us know how you go.

Hello @rd-thinlinc,

I just had a go with CF Tunnels, and made it work with an out-of-the-box installation of ThinLinc.

Could you share a bit more about your set up?

Regards,
Martin

1 Like

I have the Cloudflare connector installed on a local SYNOLOGY NAS. I have a few other public host names able to get into those exposed tunnel public hostnames.

@aaron
the vsmgent.hconf was pointing to the local IP of the Ubuntu box where I have ThinLinc Server parts installed. This is working with the client and web access locally.
agent_hostname=[local IP of Ubuntu box]

@martin
CF tunnel forwards to https://[local IP of Ubuntu]:300 << trying the Web access 1st

attempt:
The Thinlinc web logon page is OK … I enter my username and password then it shows
redirecting to ThinLinc server
https://[local IP of Ubuntu box]:300, please wait

vsmserver log shows
2023-03-17 08:23:57 INFO vsmserver.session: User with uid 1001 requested a reconnection to 127.0.0.1:10
2023-03-17 08:23:57 INFO vsmserver: Verifying session 127.0.0.1:10 for [user]
2023-03-17 08:23:57 INFO vsmserver: Session 127.0.0.1:10 for [user] is alive and ready for reconnection
2023-03-17 08:23:57 WARNING vsmserver.session: Failed to get client ip for the session

if performing the connection locally I don’t see that error. and a eventually see in the tlwebaccess log
a GET /websocket/[user]/10/
connecting to: localhost:5910

@martin
how did you setup the ‘Service’ section in CF tunnel? this may give me a clue where things go wrong

my other thought is to run another tunnel connector instance on the Ubuntu box thru docker if they allow to see if that works

2023-03-17 08:23:57 WARNING vsmserver.session: Failed to get client ip for the session

This line is safe to ignore in this case with tlwebaccess.

These are the tunnel settings I’m using:
Adjusted Type to HTTPS and URL to localhost:300
Origin Server Name to my server hostname from hostnamectl output
Also enabled No TLS Verify since the local certificate is self-signed.

Regards,
Martin

@martin

I assume the tunnel connector is running locally on that box as well? if so is it running as a docker instance or locally as a process? Mine is not local to the ThinLinc server and that may be the issue…

Correct, it’s a simple setup with ThinLinc Master, agent and connector running on same server.

/Martin

I am now setup with same as you. The ThinLinc Master Agent and connector all running on my local Ubuntu box tunnel https://localhost:300

… and get the same result … redirecting to https://[IP of local box]:300 and this stalls…

Is that IP of your lab-29 box on a public IP?

This all works when running the client from my local LAN segment … Doesn’t work from outside Internet connected client…

No, it’s a LAN ip.

ThinLinc Webacces will perform a redirect after login to agent_hostname. If this is undefined, it will be the IP address of the agent. If your client (browser) can’t reach this IP, it will eventuelly time out.

To be able to reach this from both LAN and WAN side, one can set agent_hostname to a hostname Then you will need to configure your DNS service to respond with different IP addresses, depending on the source network of the DNS query, a.k.a. Split view / horizon.

https://www.cendio.com/resources/docs/tag/network.html?highlight=nat#dns

Regards,
Martin

This redirect seem to break out of the Cloudflare tunnel if I am following you correctly or no?

Since the redirect == https://[agent_hostname]:300 < My Firewall blocks this direct access when the external DNS provides a public IP.

Is your server you setup reachable directly using the redirected public DNS address associated with the agent_hostname?

Hello,

I apologize for taking so long to respond, I’ve been busy with some other stuff.

To get this to work externally, I set agent_hostname= to my public DNS record, and I also changed the tlwebaccess port (300) to 443, so that the redirect to agent after authentication will match the tunnel configuration at CF. This was previously set to “localhost:300” at CF in the URL field. I changed it to only be “localhost”

Regards,
Martin

I now have this setup working through 443 Web access with your suggestion. Thank You.

I was also hoping to get the main full client to also work through these CF tunnel if possible?