A Jump Host for Remote Desktop Access
When Cloudflare Access first extended its Zero Trust authentication model to the Remote Desktop Protocol (RDP), the intended path required deploying Argo Tunnel—and its cloudflared daemon—on every RDP server that needed protection. For organizations managing thousands of machines, that per-server installation quickly became a bottleneck. Provisioning new daemons, updating configuration management manifests, and monitoring every tunnel across a large fleet was more than many teams could sustain during a sudden shift to remote work.
Argo Tunnel RDP Bastion mode addresses that operational burden. Instead of installing cloudflared on each destination machine, a single instance runs as a jump host inside the network. That one bastion proxies RDP requests to any internal server, so a single tunnel—gated by Cloudflare Access—can reach hundreds of remote desktops. Users no longer need to file a ticket with the infrastructure team every time they need to connect to a machine that wasn’t individually provisioned.
The Problem with RDP at Scale
RDP remains one of the most common ways employees reach office computers from remote devices. It ships by default on Windows and is supported on Unix-like systems and macOS. Heavy reliance on RDP during the pandemic has also introduced two security weaknesses. First, many RDP servers ended up exposed directly to the public Internet, either through incomplete firewall rules or unpatched vulnerabilities, as IT teams rushed to make desktops available remotely. Second, RDP authentication often relies on local passwords set and stored ad hoc, outside of corporate single sign-on systems. Those credentials tend to be reused, outdated, and weak, and they frequently guard Internet-exposed resources.
Cloudflare Access closes that gap by first locking down the remote machine with Argo Tunnel, then enforcing identity-based policy before any RDP session starts. Users authenticate with their existing identity provider—Okta, Azure AD, or another—before the connection proceeds, which lets organizations apply the same password strength and rotation standards they use for other critical tools.
Bastion Mode in Action
The architecture differs from the usual cloudflared model in a key way. In a conventional tunnel, cloudflared opens a single outgoing connection to a preconfigured origin. In bastion mode, the origin-side cloudflared instance reaches out to the two nearest Cloudflare edge data centers and establishes a long-lived HTTP/2 session. It then waits for incoming connections to specify which internal destination to reach.
On the client side, a separate cloudflared instance is configured not with the bastion’s address, but with the internal hostname of the machine the user wants to access. The user’s RDP client—Remote Desktop Connection on Windows, for example—connects to that local cloudflared process. The client then opens a browser window, takes the user through the Access login page, and accepts authentication from the chosen identity provider.
Once authenticated, the client tunnels the RDP traffic as HTTPS requests to the Cloudflare edge, carrying the final destination and an Access JWT in the request headers. The edge verifies the token, checks the user’s authorization, and forwards the connection to the bastion using Argo Smart Routing’s shortest-path PoP-to-PoP route. For each connection, the bastion opens an outgoing RDP session to the final internal destination and proxies traffic in both directions.
Bastion mode currently handles RDP traffic only, but Cloudflare plans to extend the same proxying model to FTP, SSH, and generic TCP in the future.
