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
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.
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.
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ā¦
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.
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ā
