Cloudflared tunnel setup for Zero-trust RDP doesn't work!

[Akshay]

Hi there,

I’ve wanted to access RDP over cloduflared/Cloudflare Tunnel . I’m trying to follow the guide at: RDP · Cloudflare Zero Trust docs exactly and I’m having issues accesing my machine over RDP, as this error is getting logged “ERR failed to connect to origin error=“websocket: bad handshake” originURL=https://redacted”

I’m not sure what’s wrong with my account, I’ve tried with different hosts and websites and none of them are working and all of them are showing the same error as described above. I’ve even added a newer domain to the account as well that I’ve added to Cloudflare, and still facing the same issue on the site. This looks to me like a clear bug. I have attached all relevant files with this and can confirm Websockets is enabled from the network tab and SSL setting is not set to off and having universal SSL enabled.

Just to clear an ambiguity in the screenshot attached, I’m accessing the RDP instance from the same machine in separate terminals (side by side) - with one tunnel running cloudlfared outbound connections to Cloudflare and other as a local RDP forward command; but in reality, even if I’m accessing from a different machine, the error is existent.

Requesting to kindly check and suggest what may be wrong as I’m following the guides exactly. I’ve attached all relevant screenshots.Any help here would be appreciated.

Thanks!

- Access Policy Configured

- DNS setting

- Tunnel Config

- Cloudflared error logged while accessing the service. Left Window (cloudflared outbound connection), Right Window (RDP → local tunnel commands)

Cloudflare Ticket #2200903 (got closed as I’m on a free plan).

[cs-cf]

By default Windows is looking for the config.yml in C:\Windows\system32\config\systemprofile\.cloudflared\config.yml

You can add a log file line to the config.yml to log/confirm the connection attempt.

logfile: $somepath\tunnel.log

[Akshay]

Thanks for the reply.

I’ve copy pasted the updated config file at the location you’ve mentioned. It still doesn’t work and shows the same error.

As for logs: there’s no hits/connection attempt logged. The last message is a connection registered message, and no, the config file is being used from .cloudflared directory in the user account (I’ve differentiated log path filenames in each config file at either location). I’ve restarted everything post updating the config.

Further, if you see the screenshot, it’s picking up the config at the .cloudflared dir from the account root.

Thanks

[cs-cf]

Reboot and try again? Something may be running as a background process.

[Akshay]

Thanks again, however, nothing appears to have been changed. I’m getting the “ERR failed to connect to origin error=“websocket: bad handshake” error. Can you please ask this to be looked internally, this has to do something with my account. I’ve tried on different OSes and Platforms and this is consistent.

Thanks!

[nuno.diegues]

Sanity check: can you RDP without going through the tunnel? i.e., if you put localhost:3389 in your RDP client, does it work?

[Akshay]

Yup, RDP works fine otherwise, and no firewall rules exist to block any connections.
I’ve investigated thoroughly. There’s a bug with Windows cloudflared.

INF Cannot determine default configuration path. No file [config.yml config.yaml] in [~/.cloudflared ~/.cloudflare-warp ~/cloudflare-warp]

is logged when starting a tunnel, can confirm there exists %USERPROFILE%\.cloudflared dir and a config.yml file.

Can you please check this bug? cloudflared, for some reason, is unable to identify the config at %USERPROFILE%\.cloudflared.
cc: @cs-cf

Thanks!

[nuno.diegues]

If you provide the path to the config explicitly (via --config <path>) in cloudlared tunnel --config <path> run, does it work?

[Akshay]

@nuno.diegues

cloudlared tunnel --config run

Tried it, here’s where the problem lies, it doesn’t seem to honour that syntax:

C:\Users\Administrator>cloudflared tunnel --config “C:\Users\Administrator\.cloudflared\config.yaml” run

“cloudflared tunnel run” requires the ID or name of the tunnel to run as the last command line argument or in the configuration file.
See ‘cloudflared tunnel run --help’.

[Akshay]

As a hint: I tried the same with a local HTTPS server and it too was getting the same error. While manually using a ‘free tunnel’ and redirecting the traffic to localhost:443, it then worked (confirming reachability), I’m assuming there’s something wrong with the binary that it’s not reading config files as the port is chosen to be 8080 by default and is accessing that, even when running: cloudflared tunnel run is used and not the intended port. There’s no errors/typos in the config file.

Thanks again.

[nuno.diegues]

I have tested that on a Windows VM and it worked fine as expected:

I can see that the hello-world: true configuration property from my config.yml got picked up in the CLI output.

PS: I cannot test the end to end with RDP since my windows VM is home edition and thus does not have RDP server.

[Akshay]

Interesting. I’ve identified the problem.

cloudflared.exe was in my path (per the docs) - and was placed at: C:\Cloudflared\bin\cloudflared.exe

This still causes the cloudflared to ignore the working directory and causes the error I’ve mentioned above. I’ve removed from path and opened a terminal in the directory of the binary as you’ve did and it works.

This shouldn’t be the case irrespective of where the binary is existing, as config path is being passed in explicitly in the param. There’s an inconsistent behaviour here if cloudflared is invoked from %PATH%.

Thanks, I’ll file a Github issue. This has more serious complications, from aside the fact that the documentation refers to the default path everywhere and that this results in an unrelated error of bad handshake.

[Akshay]

Apparently that too didn’t work. I’m trying on different machines it isn’t working with the RDP config that I’m using (from the examples)