RD Gateway Alternatives for MSPs: Browser RDP Without an Internet-Facing Gateway

Remote Desktop Gateway is the default answer when someone needs RDP from outside the office without a full VPN. It is built into Windows Server and it gets RDP off port 3389. For an MSP managing dozens of client sites, though, it is a server to build, patch and expose at every one of them, and it only carries RDP. Here is what RD Gateway actually requires, and where a per-site WireGuard tunnel fits better.

What RD Gateway is, and what it needs

RD Gateway is a role service of Remote Desktop Services in Windows Server. It wraps RDP inside HTTPS, so a remote Remote Desktop client connects to the gateway on TCP 443 and the gateway opens the RDP session to the internal machine. Microsoft's own port reference for RDS lists two inbound ports from the internet to the gateway:

TCP 443 for HTTP (including RPC over HTTP) over SSL
UDP 3391 for RDP over UDP

Both ports can be changed, but something has to listen on the public internet. A working deployment also needs:

A Windows Server at the site to host the role.
A valid SSL certificate bound in RD Gateway Manager. The service refuses connections without one, and a self-signed certificate means every client device has to trust it manually.
A public IP or a port forward to that server, plus a DNS name that matches the certificate.
A Connection Authorization Policy (RD CAP) for who may connect, and a Resource Authorization Policy (RD RAP) for which computers they may reach. Users cannot connect until at least one RD CAP is enabled.

For one company with an RDS farm, that is reasonable. Across forty small clients it is forty internet-facing Windows servers you are responsible for.

The exposure problem is not theoretical

An RD Gateway has to accept traffic from anyone before it knows who they are. In January 2020 Microsoft patched CVE-2020-0609 and CVE-2020-0610, two critical remote code execution flaws in RD Gateway on Windows Server 2012 and later. Both were exploitable without authentication or user interaction, and both were reachable through the UDP transport. CERT/CC's suggested workaround for unpatched servers was to disable UDP transport or block UDP 3391 at the edge.

Patching fixed those two. The structural point remains: while the gateway listens on a public address, every future bug in that listener is reachable from the internet.

It only carries RDP

Microsoft describes RD Gateway as providing a point-to-point RDP connection rather than access to the whole internal network. That is a good security property, and it is also the limit of the tool. An MSP engineer on a typical ticket needs more than RDP:

The firewall or router web UI
The NVR, the PBX admin panel, the UPS network card
SSH to a switch or a Linux box
VNC to a machine that is not Windows

RD Gateway reaches none of these, so the MSP adds a VPN, port forwards or an agent for everything else. Each is another path into the client network.

The alternative: one outbound tunnel per site

ProxyLink flips the direction. The client's router (MikroTik, pfSense, OPNsense, OpenWRT and others) or a Linux gateway connects out to ProxyLink over WireGuard. Nothing at the site listens on the internet: no port forward, no public IP, no certificate to renew. It works behind CGNAT for the same reason.

That one tunnel covers the whole LAN and any additional VLANs you declare. From there, every device is a link in the ProxyLink dashboard:

Browser RDP to any Windows machine on the LAN. No Remote Desktop client and no gateway server: the session runs in a browser tab, with file transfer and multi-monitor selection from the toolbar.
Browser SSH and VNC for switches, Linux hosts and Macs.
HTTP and HTTPS links to web UIs: routers, NVRs, PBXs, NAS boxes, UPS cards.
TCP and UDP links for anything else that needs a raw port.

Nothing is installed on the target devices.

Access control without CAPs and RAPs

RD Gateway scopes access with CAPs and RAPs built on AD groups, configured per gateway. ProxyLink scopes it centrally across every client:

Client groups per site, so a tunnel and its devices belong to one client.
Team roles: owners see everything, engineers see their assigned clients, employees see only the devices assigned to them.
Per-site isolation on the VPN, so a device at one client cannot reach devices at another.
Session recording, opt-in per link, for RDP and SSH sessions, plus an audit log.

Every gateway also gets its own translated range, so ten clients all on 192.168.1.0/24 are reachable side by side.

When RD Gateway is still the right tool

If a client runs a full RDS deployment with RemoteApp programs published to end users, RD Gateway belongs in that design. ProxyLink is built for MSP engineers reaching client infrastructure, not as an RDS farm's user front end. Many MSPs will run both.

Where RD Gateway exists only so the MSP can reach the server, an outbound tunnel removes the listener and the certificate, and adds every non-RDP device on the network.

Try it on one client site

ProxyLink is free during early access, with no card needed. Set up one tunnel on a client router, open a browser RDP session, then close the port forward to the gateway. Start at app.proxylink.dev, and see the setup guides at proxylink.dev/docs.