Cloudflare Access - CLI Auth Beta

We’re busy planning how to extend Access in more directions, mTLS included. Stay tuned!

1 Like

I’m using Cloudflared 2019.4 for integrating Cloudflare Access with an existing python application that sends requests to a web API. It’s working fine, but the developer experience is not ideal. I would really appreciate a json output option and the use of return codes for access login. Since now it always returns 0 and the only way for me to get the token is to parse the human-readable text by breaking it into lines, searching for the line that contains Successfully fetched your token: and then taking the next line.

I have a problem with the cloudflared access tcp command on Windows.

I configured a host (the internal server) according to the documentation for tunneling arbitrary tcp ports. Now I try to connect two clients — one is running Mac OS X and the other is running Windows 10:

  • The Mac OS X works great (although I had to install cloudflared by hand because the Homebrew one lacked the access tcp subcommand). I execute cloudflared access tcp --hostname [host] --url localhost:5432, a browser window with the SSO prompt opens, I log in, the connection works.
  • On Windows 10 the browser window never opens. I execute C:\cloudflared.exe access tcp --hostname [host] --url localhost:5432 and nothing happens. The command outputs INFO[0000] Start Websocket listener on: localhost:5432 and that’s it. There is no way to authenticate.

On Mac OS X I use cloudflared version 2020.4.0 (built 2020-04-14-1853 UTC), and on Windows it is 2020.4.0 (built 2020-04-14-1858 UTC). Both freshly installed.

Thanks for the report, Ludwik.

Could you try sending a request through that localhost port that you have created on the Windows machine to see if that triggers the auth prompt?

When I use RDP it requires a request through the tunnel for it to request auth.

Also, since when are random TCP ports allowed via Argo Tunnel?!

1 Like

I just tried this and got my hopes up, alas, it does do arbitrary ports but still only the SSH protocol. It would be really nice if tunnel could create and tunnel as a Spectrum application.

Edit: actually maybe it does, but I wasn’t able to get it working for my arbitrary TCP protocol for my mmo game.

Oh, really? I am sad :disappointed:

Thanks for trying though!

edit I’ll try then… will report back.

Think this might have been related, although I’m not sure.

Reporting back… here’s what I was able to do.
For reference, the domain I’m testing on does have Spectrum TCP, but it doesn’t look like that matters.

docker container i’m using:

"Environmental variables map[ TUNNEL_URL:tcp://haproxy:7198]"
time="2020-04-27T01:40:40Z" level=info msg="Proxying tunnel requests to"
time="2020-04-27T01:40:40Z" level=info msg="Connected to ATL" connectionID=0

With this I see the tunnel in the network app and DNS app.

Now, on Windows:

.\cloudflared.exe access tcp --hostname --url
INFO[0000] Start Websocket listener on:

Go to the URL in my browser (Access is on and protecting subdomain at this point):

A browser window should have opened at the following URL:


If the browser failed to open, please visit the URL above directly in your browser.
ERRO[0019] failed to connect to  error="websocket: bad handshake"

And, with that error, trying to connect via tcp to (or doesn’t work.

Why is it saying proxying tunnel requests to Shouldn’t it say at least TCP?

I don’t have TCP services (which don’t require UDP as well) running, I only have HTTP ones.

I would suspect that’s the HTTPS port that shows the "you’re authenticated with CF access " page. My TUNNEL_URL was tcp://haproxy:7198 so anything happening is probably the tool’s fault.

I tried to connect to a remote SMB share, using the standard TCP method, it worked for me (it was even to a third host on the remote network). I used the the IP though, maybe the hostname as url fails due to some DNS thing (doesn’t use the default hosts file?). Try using IPs all the way through.

Figured out the issue: I turned off websockets for that zone since I had no intentions of using websockets. It looks like it works now, although since my Spectrum application uses Proxy Protocol, I can’t actually use this tunnel :upside_down_face:.

In the sense that you can’t use the SOCKS protocol? I believe you can, using the --socks5=true flag.


I’m talking about spectrum’s Proxy Protocol feature, which sends the user’s real IP via the TCP connection.

Argo tunnel on the server doesn’t seem to be able to do that. I also need a full TLS handshake with the client and server’s actual presented certificates so a SOCKS proxy would break that.

I see, maybe we should call in the man himself: @SamRhea, he would probably know more than I do.

1 Like

That’s correct - we won’t be able to send the full TLS handshake from client to origin here, or the real IP through the TCP connection like in Spectrum. Looking at ways to solve that down-the-road though.

1 Like

Reverse tunnelling raw TCP connections in the same fashion as HTTP would be very useful for our use-case as well! Effectively, having something that won’t require the client to use cloudflared commands.

There are huge advantages in security architecture design to be able to reverse tunnel connections as opposed to opening firewalls/NATing.

Definitely +1 for this feature! :smiley:

You could package the .exe (or binary file) and attach a shortcut. I just did that today to substitute a VPN that was misbehaving on the user’s side.

@SamRhea it’s unfortunate, but most likely impossible to remove, the fact that the VPN seems faster that the TCP tunneling. This is done empirically, but the user felt it was slower than the VPN connection. Obviously it helps with every other connection and security is way higher.

Thanks @matteo! That’s my current solution. :slight_smile: