jeffers.me

Remote desktop in a browser tab, with no client and no open ports

I tried Cloudflare Access's browser-based RDP against a Windows VM in the lab. It worked on the first try, and it changed how I think about remote access.

Published
Length
2 min, 1U

Remote access to machines at home has always been the part of my lab I was least happy with. I’ve used port forwards (briefly, a long time ago), VPNs that worked until they didn’t, and a self-hosted remote desktop tool I never configured as carefully as I should have.

This week I tried Cloudflare Access’s browser-based RDP against a Windows 11 VM. The short version: I opened a URL on my phone, signed in with my Google account, and got a Windows desktop in the browser. Nothing installed on the phone, nothing listening on my home connection.

How the pieces fit

There are three parts, and I already had two of them.

  1. A Cloudflare Tunnel. A small connector inside the network dials out to Cloudflare. Nothing inbound is ever opened on the router.
  2. An infrastructure target. This tells Cloudflare which private IP the VM lives at, reachable through the tunnel.
  3. An Access application of type RDP. It ties a public hostname to that target, puts an identity policy in front of it, and renders the session in the browser.

The browser client is built on IronRDP, an open-source RDP implementation in Rust compiled to WebAssembly. Cloudflare terminates the identity check at the edge; Windows still asks for its own credentials once you’re through.

What I liked

  • No client. It works on anything with a modern browser, including a locked-down work laptop or a phone.
  • Identity first. The Windows login screen isn’t reachable from the internet at all. You have to get past Google sign-in and the Access policy before RDP is even attempted.
  • Session length is a policy, not a habit. I set eight hours. After that, sign in again.
  • It’s one more app in the same dashboard as everything else I publish through Access, so there’s one place to audit who can reach what.

What to watch

  • Clipboard and file transfer are more limited than a full RDP client. For admin work that’s fine; for moving lots of files it isn’t.
  • It’s RDP only. For Linux machines I use Access’s browser SSH instead, which works the same way.
  • Your Windows accounts still need good passwords and, ideally, separate admin accounts. Access in front doesn’t excuse weak credentials behind.

Where this leaves my old setup

I’m planning to retire the self-hosted remote desktop server I’d been running. It had more moving parts, more ports, and I’d never fully locked it down. The browser approach is simpler to reason about, and simpler is usually safer.

Next I want to try it with a hardware KVM for machines that don’t have an operating system running yet. That’s the one case a browser RDP session can’t cover.