The RD Gateway allows RDP clients to communicate over the internet through an HTTPS tunnel, thus saving organizations the need to set up a VPN. Talking to the RD Session Host, the gateway uses pure RDP on port 3389 by default. Access can be restricted to certain resources and users.
Relationship to RD Web Access ^
The RD Gateway is one of several server roles for Remote Desktop Services. RD Web Access, another RDS role, is also an entry point for remote desktop clients. It allows the start of a desktop or a RemoteApp from the web browser.
Accordingly, one could assume that RD Web Access could be used as an alternative to an RD Gateway. But this is not the case. As expected, the clients can also access the web interface via HTTPS, but opening an application leads to an unsecured RDP connection to a session host. RD Web Access can, however, be combined with a gateway to make access easier for users.
Placement of the gateway in the internal network ^
In a simple configuration, you could place the RD Gateway in the LAN and open firewall port 443 for external access to the gateway. You also need a public DNS record so that clients can resolve the name of the gateway.
However, this configuration is not very secure, as it allows an intruder to move laterally through the network if he compromises the RD Gateway. You can therefore protect it by placing a reverse proxy in the DMZ, which forwards the requests via HTTPS through the firewall to the gateway.
Gateway in the DMZ ^
Alternative deployment options assume that an RD Gateway does not run in the internal network, but rather in the DMZ, which is usually shielded internally and externally by firewalls.
In the internal facing firewall, port 3389 must be open for the RDP toward the LAN and externally port 443 for the SSL connection from the internet. However, if the RD Gateway is a member of an AD domain, then a whole series of ports must be opened toward the internal network for communication with the DC.
An older post from Microsoft's RDS Team Blog lists the following functions that require access to internal resources:
- Authentication and authorization of users
- Resolving the names of internal resources
- Obtaining the certificate revocation list
- Sending RADIUS requests (if a central NPS server is used)
Reduced traffic with a workgroup server ^
Much of this communication can be avoided by configuring the RD Gateway as a workgroup server instead of joining it to an AD domain. This has been supported since Windows Server 2008 R2.
But the configuration is more complex than with a member server, and then you have to manage all permitted users locally. In addition, GPOs are no longer available for the management of the server, and local group policies must be used instead.
RODC in the DMZ ^
To avoid extensive communication with a domain controller in the LAN and still not have to forgo the AD integration, it makes sense to place a read-only domain controller (RODC) in the DMZ.
The RODC belongs to the internal AD forest and authenticates remote desktop users. Its communication with the internal network is restricted to replication with the DCs in the LAN.
Dedicated forest in the DMZ ^
A similar result can be achieved if you set up your own forest in the DMZ and create a unidirectional trust relationship to the internal forest. The RDS Gateway is a member of the DMZ domain; hence, the RDP users authenticate against the DC there.
Here, AD-related traffic is reduced to that which is necessary for the trust relationship.