Remote Desktop Gateway basics
Remote Desktop Gateway gives remote users a path to internal desktops and RemoteApp programs without publishing RDP itself to the internet. A client connects to the gateway, the gateway applies its access policies, and it brokers the RDP session onwards to an internal host. Microsoft describes the role as enabling encrypted connections to Remote Desktop Services resources over the internet, so that users reach internal resources without a VPN (Deploy the Remote Desktop Gateway role).
Why direct RDP exposure is a problem
An RDP port open to the internet is visible to every scanner on the public network. Brute-force attempts against exposed RDP are routine, and the resulting traffic adds log noise that hides the interesting events. Even with strong credentials in place, the exposure gives an attacker a place to keep trying.
A gateway removes the direct path from the internet, but it does not remove the exposure. The gateway becomes the published endpoint instead, so it needs its own patching, access controls and monitoring. The destination hosts still need protection too.
What actually crosses the network
Moving RDP behind a gateway changes where traffic is allowed rather than what a session contains. Two directions matter.
From the client to the gateway:
- TCP 443 carries the gateway's HTTPS transport. It must be reachable by the intended clients, directly or through a compatible front end.
- UDP 3391 carries RDP over UDP and can be configured in the gateway console. It is optional, and it is there for the UDP transport.
From the gateway to the internal hosts it serves:
- TCP 3389 carries RDP by default; UDP 3389 may also be used when the deployment enables UDP transport. Use the actual configured ports if they differ.
The gateway also needs the identity and name-resolution services its configuration depends on. These can include Kerberos, LDAP, RPC and DNS, plus RADIUS on UDP 1812/1813 when NPS is used. Determine the required paths from the actual roles and authentication flow rather than opening a broad range without a reason.
These are the published port requirements (Ports That Are Used by RDS).
The internal hosts still need an inbound RDP rule. Scope it to the gateway and any separately justified management sources, rather than an unrestricted network range. Hiding RDP from the internet does not remove the internal rule, it changes which source the rule allows.
Two policy types, two decisions
Two policy types shape the decision. A connection authorisation policy, or CAP, sets the requirements for connecting to the gateway, so it decides who may reach the gateway at all. A resource authorisation policy, or RAP, decides which internal computers those users may connect to through the gateway. A session has to satisfy one CAP and one RAP, which is why keeping the two apart matters: a user allowed through the gateway does not automatically gain access to every destination behind it.
CAPs are stored locally by default, or in a central store running Network Policy Server, and they can also be evaluated as RADIUS requests. RAPs are processed on the gateway itself and cannot use a central policy store.
Write CAPs around named groups with a clear owner, and write RAPs around the specific computers each group needs for its role. A group that administers a handful of servers should not carry a RAP that covers every host in the environment. The policies should describe the work rather than the other way round.
Identity and access hygiene
Grant access through named groups with a clear owner. Shared accounts and generic admin identities make it impossible to say who accessed what, and they turn a stolen password into access to everything that account reaches. Remove access when the need ends.
RD Gateway supports certificate-based (smart card) authentication and password authentication, and the permitted method is chosen in the gateway configuration. When passwords are allowed, MFA usually comes from outside the gateway. RD Gateway acts as a RADIUS client towards Network Policy Server, NPS verifies the credentials and enforces its own policies, and the Microsoft Entra MFA extension performs the second factor (Plan Multifactor Authentication for Remote Desktop Services).
That integration has limits worth knowing before you promise MFA to users. The Entra MFA sign-in for RD Gateway offers phone call and Approve or Deny push notifications from the Authenticator app, and there is no code entry option, so SMS text does not work for this sign-in and an account registered only with a TOTP code cannot meet the challenge. The NPS extension belongs on the NPS server rather than on the gateway, and the gateway has to be pointed at a central CAP store for the flow to work (Integrate RD Gateway with Microsoft Entra multifactor authentication).
An allow-list can narrow source locations when that fits the work pattern, but it should not replace strong identity checks. Travel and shared network exits make location an imperfect signal. Review group membership and gateway logs, and remove access when a need ends. An employee who has changed role should not still have gateway access to their previous group of servers.
Placement and hardening
Do not expose RDP directly to the internet. A gateway reduces that direct path, but it still needs timely updates, strong authentication, and monitoring of the gateway logs and alerts. Place it where it can reach only the systems it must serve. A gateway that can reach every host in the environment is one misconfiguration away from being a universal entry point.
The gateway also needs a certificate for the name that clients connect to. Microsoft recommends a publicly issued certificate for the role, since the gateway is exposed to the internet, and if you use a private certificate you have to trust its chain on every client beforehand.
Treat the gateway as a high-value target by design and keep it patched. The Microsoft-Windows-TerminalServices-Gateway/Operational channel records the decisions that matter: event 200 shows that a user met the connection authorisation policy, and event 300 shows that the user met the resource authorisation policy. On NPS, Security events 6272 and 6273 record granted and denied network access. They do not by themselves prove that a desktop session was established (Microsoft, Audit Network Policy Server). Review those logs and alert on patterns that do not belong, such as sign-ins from unusual places or attempts to reach hosts outside the set a group works with.
Documentation and testing
Document the route. Record which users sit in which CAPs, which hosts are named in which RAPs, and what the expected sign-in flow looks like. Test allowed and denied cases. Confirm that a permitted user can reach the intended computer, and confirm that another user or another destination is rejected.
Maintain a recovery route for administrators that does not depend on an unavailable gateway. If the gateway itself has an issue, there should be a known way to reach critical hosts, even if that way is narrow and closely logged. A well-scoped gateway is one layer in a remote access design, and it does not replace endpoint security or account hygiene.
Checklist
- Keep RDP off the public internet and provide the intended clients with an HTTPS path to the gateway.
- Allow the configured RDP ports from the gateway to the intended hosts. Add UDP only where it is used, and document any separate management access.
- Separate CAP and RAP policies, and write each around named groups and named computers.
- Choose the authentication method explicitly, and enforce MFA through Network Policy Server when passwords are allowed.
- Keep the gateway patched, and read the TerminalServices-Gateway log for events 200 and 300.
- Test allowed and denied paths, and keep an administrator recovery route that does not depend on the gateway.