SSH & VNC browser rendering fails

I’m trying to use SSH and VNC browser rendering with a Raspberry Pi connected to a Cloudflare Tunnel. When loading the URL configured for either of the two, I log in and it shows the renderee view for less than a second before showing an error page. My browser devtools show that a POST /cert_sign results in a 400 Bad Request with the following message:

{"message":"Bad Request. Please create a ca for application."}

However, another request appears which shows a WebSocket connection that appears to be proxying to my SSH server correctly. I can see the proper SSH-2.0-OpenSSH_7.9p1 Raspbian-10+deb10u2+rpt1 being sent just fine, as well as certificate negotiation, but the page won’t go any farther because of the failure earlier from the POST request.

I don’t want to use short lived certificates, as I want to share this domain with multiple people and each of them have their own separate shell login and profiles.

I opened a support ticket and it got instantly closed by a bot, so I’m hoping a resolution can be made here on the forums before me having to wait 72 hours to get the support I wanted in the first place.

1 Like

Can you share your ticket number here?

My ticket number is #2254414.

1 Like

This thread has been put into the escalation queue.

Had a similar issue with SSH, I generated one short-lived certificate and the issue was fixed. Note, I don’t use them, but I remember that SSH rendering wasn’t working, and doing this fixed the issue.
I also had to disable TLS-Verify on the tunnel config.

Regarding VNC, I still face a similar problem where the connection is established but shortly after its just closed.

I went ahead and generated short-lived certificates for both the SSH and VNC apps, and my devtools are now showing the POST /cert_sign succeeding. However, I’m still seeing the same error page. I tried on a different computer and SSH worked fine, except the login methods are different (my own pc used github, other pc used email otp). I tried logging out and logging back in, in case I needed a fresh login after creating the certs, but it didn’t fix the issue. I also thought it was maybe my adblocker since the other pc doesn’t have one but that also didn’t change anything.

Another new issue, the VNC browser renderer doesn’t seem to support the authentication methods that the server is sending. Here are the console logs (prefixed by the level of the log, not originally part of the log):

[debug] >> WebSock.onopen
[debug] Starting VNC handshake
[debug] >> WebSock.onopen
[info ] Server ProtocolVersion: 005.000
[debug] Sent ProtocolVersion: 003.008
[debug] Server security types: 13,5,6,130,192
[error] Failed when connecting: Unsupported security types (types: 13,5,6,130,192)
[debug] New state 'disconnecting', was 'connecting'.
[debug] >> RFB.disconnect
[debug] >> Keyboard.allKeysUp
[debug] << Keyboard.allKeysUp
[info ] Closing WebSocket connection
[debug] << RFB.disconnect
[debug] New state 'disconnected', was 'disconnecting'.
[debug] Clearing disconnect timer
[debug] >> WebSock.onclose
[debug] << WebSock.onclose

Do you get this error on the VNC rendering app?
The origin has unexpectedly closed the connection. Please confirm that the origin is healthy.

I definitely received that error at some point, but currently the VNC rendering app just shows an “unexpected error” (original pc).

Not 100% sure, but this seems to be VERY similar to the issue that I have been facing for the last 2 weeks.

Cloudflare is investigating it and there have been at least 2 escalations of the ticket, however, I didn’t receive any clear answer just yet.
I tried to set up the VNC tunnel in multiple machines and all of them drop the same error.

I think my issue may be slightly different, as I can’t get it to start in the first place because it doesn’t support the server’s security types. Out of interest, what are your debug logs? I noticed in Chrome they’re actually called “Verbose” but it’s still the same.

Hm, it didn’t even log the version handshake between the two. Maybe check the WebSocket connection in the Network tab and see what messages were exchanged? If there’s an incoming version header, something’s definitely wrong on Cloudflare’s end. If there’s not, it could still be Cloudflare or some odd issue with your Cloudflare Tunnel configuration.

Here’s my config for SSH + VNC (note the vnc:// prefix, I don’t know if this even makes a difference or if it’s documented anywhere but I used it anyways while I was adding the subdomain).

tunnel: [...]
credentials-file: /home/pi/.cloudflared/[...].json

  - hostname: [...]
    service: ssh://localhost:22
  - hostname: [...]
    service: vnc://localhost:5900
  - service: http_status:404

¡Hola @glitchmasta47! has a slight different line in the config.yml file, namely:

  service: tcp://localhost:5901

instead of:

    service: vnc://localhost:5900

Please make sure to update the port number as per your exact configuration.

On a Raspberry Pi 3, I could only make VNC work with set to VncAuth.

SSH worked straight away with @jgc’s very thorough blog post over at

Hope this helps.


1 Like

The vnc:// prefix still seems to work totally fine with Cloudflare tunnel. As far as the authentication method goes, I do understand why VncAuth would be required since the other methods seem to be RealVNC-specific, however an important part of my VNC setup is having two different usernames with different passwords. I think the only solution I could do is supporting my existing authentication method and adding VncAuth as a fallback for Cloudflare Access. I’ll try this soon and let you know the results.

Adding VncAuth as a fallback method resolved my issues with VNC and it seems to be working fine now. I think all the issues I originally had have been resolved, however this wasn’t the most pleasant experience and I’d definitely recommend either documenting the requirement of at least one short lived certificate, or fixing the issue that requires the short lived certificate when it’s not needed.

  • VncAuth is the only scheme that allows direct connections from non-RealVNC VNC Viewers.

I guess makes sense but surprises me that there was no way to track it down. Once I’m on my desktop later, I will deal with it and see if it fixes the issue for us as well.

Still having issues on my original computer using either of the two. Same “unexpected error” except no requests have failed and the browser console doesn’t have any error details other than the generic error boundary being thrown.

Here I am, facing the exact same error. Is your backend a windows server?

Okay, so I got the browser to ask me for a password once! ( It won’t work after that tho ).
I disabled the encryption and set the password to vncauth and it accepted the login once, only to get back to the weird error.

The SSH/VNC server I’m trying to connect to is a Raspberry Pi 3B+ and the client machine that is unable to connect is a Windows 10 desktop.

For the times that I can get VNC working (on other devices), adding VncAuth worked perfectly. Maybe you’re now running into some other issues during handshaking?