SSH forward, VPN or RD Gateway: which path for one RDP desktop

All three options carry RDP, so the protocol is not the deciding factor. The real question is how much reachability one user should get, and who operates the thing that grants it. A forwarded TCP port, a routed private network and a desktop gateway answer that question in three different sizes. Pick the size first and the product follows.

The question is scope, not protocol

Write down what the user actually needs to touch. If the answer is one desktop, a design that grants a subnet is over-scoped. If the answer is a desktop plus file shares plus an admin console, a design that forwards one port will be back for two more forwards next month. The list of destinations is the requirement; everything else is implementation.

Keep the entry identity separate from the Windows account that signs in to the desktop. Every design below has both, and conflating them is how a jump host account ends up with more authority than anyone intended.

One forwarded TCP service

An approved SSH jump host can forward a local listener to the RDP service it can reach. Bind that listener to loopback when it exists only for the user's own machine, which is the normal intent of a local forward. The forward is a convenience for one person, not a service for a team.

The SSH login authenticates access to the forwarding path, and nothing more. Windows authentication and RDP authorisation still happen at the destination, so a valid jump account is not a valid desktop session. Those are two independent gates and both have to open.

Restrict the jump account's forwarding destinations rather than granting an unrestricted shell. This design suits a small, explicitly listed set of machines, and it adds a host, an identity and a lifecycle to operate. That extra host is the part people forget when comparing it to a gateway: someone has to patch it, monitor it and own its keys.

A routed private workspace

A VPN gives private DNS and access to several services used together, which is its actual value. Hiding one desktop port is a side effect, not the reason to build it. That distinction matters when someone asks why the VPN exists at all.

Restrict routes and resource permissions to the intended destinations. A connected user does not automatically deserve the whole LAN, and the destination firewall plus Windows sign-in rights remain separate boundaries that the VPN does not replace.

This arrangement is convenient for an established managed workspace. The cost is that onboarding, device requirements, resolver behaviour and connection policy become part of the user's working environment, and someone has to own them. Compare that cost against the gateway's licensing before assuming the VPN is the cheaper option.

An RDP-specific gateway

Remote Desktop Gateway provides an RDP-specific boundary rather than a network one. Its connection authorisation policy decides who may connect, and its resource authorisation policy decides which internal resources they may reach through it. Both policies are part of the product, not optional extras.

Plan certificates, identity integration and required transports together. The gateway is not an anonymous TCP relay, and deploying it as one skips the policies that justify it in the first place. It also carries licensing and operational requirements that a single forwarded port does not. Budget for those before the design review, not after it.

Where a team already runs central desktop access, that overhead is already paid. Where one person needs one machine, it is a large machine to buy for a small job.

What all three still need

Preserve host identity checks in every design. A local alias or a tunnel does not make an unexpected certificate harmless, and accepting a mismatched one to get through a proxy defeats the point of the tunnel. The name in the client and the name on the certificate have to be reconciled deliberately.

Apply MFA at the entry point where policy requires it, and keep the destination's account controls. The two are complements: the first decides who may reach the door, the second decides who may open it. Dropping either one leaves a design that looks complete and is not.

Choose the boundary that matches the work and the operating model you actually have. The RDS role overview describes the gateway's place among the session host and other components, which is the context that makes its cost legible.