Standalone RD Gateway Server without RDS Infrastructure

Article applies to: Windows Server 2012 / 2012 R2 / 2016 / 2019

Remote Desktop (RD) Gateway Overview

This feature is specifically useful for accessing servers hosted in a public cloud such as Azure / AWS from the Internet without needing to configure a VPN connection. It helps to reduce the attack surface on your Windows-based instances while providing a remote administration solution for administrators. 

In fact, you can configure RD Gateway server with on-premise networks (Typically DMZ) as well. RD gateway can control who can connect / RDP and to which internal server. It controls this with Network Policy Server (NPS) component. I feel this is better than allowing point to site VPN connections where partial / entire internal networks would be exposed.

RD Gateway could be one of the good alternatives to allow remote server management / access as compared to paid tools. It does need a server OS license and public IP, but that should not be a roadblock for infrastructures that are hosted in the cloud. Cloud providers can take care of Virtual server hosting, licensing and public IP with reasonable rates. It does not require RDS CALs. It does need a publicly trusted SSL certificate but one can get it from Let's Encrypt for free or if you already have a wildcard SSL certificate, you can use that.

RD Gateway is basically developed to allow secure connectivity to an RDS application infrastructure from the Internet. RD Gateway should be hosted in a DMZ / isolated network segment if available. It comprises of two components; RPC-Http/Http proxy and NPS. A Proxy component allows RDP connections encapsulated in an HTTPS proxy tunnel to internal resources from the Internet and NPS validates users credentials with domain controllers and evaluates CAP and RAP policies that grant resource access based on configured policies.

From 2012 Server onwards, RD Gateway supports RPC over HTTP, HTTP and UDP based transport protocols encapsulated in SSL tunnel to connect to internal resources. RDP client 8.0 and above do support pure HTTP based encrypted RDP connections encapsulated in SSL tunnels from the Internet. Prior clients do support RPC-HTTP based encrypted RDP connections encapsulated in an SSL tunnel from the Internet.

RD Gateway Deployment and Configuration

Initial Deployment

For this demonstration, I have used Azure cloud servers (Windows server 2012 R2) and RD Gateway deployment would be used to access Azure servers from the Internet. All we need to do is to publish the RD Gateway server on the Internet over HTTPS / SSL. 

The server should listen on TCP 443 and UDP 3391 inbound. The server encapsulates RDP protocol in HTTPS tunnel and the connection remains encrypted. The server can be a part of a workgroup or can be domain member that provides more controls in a domain environment. I had a lab AD domain already set up in Azure and the server was already joined to this domain.

The server should have at least 4 GB memory with dual CPU cores, however, 8 GB memory is recommended based on my experience and there are no special disk space requirements for the RD gateway server. Since this variant is meant for RDP in administration mode, connections are limited and even a minimum hardware config would be fine.

We can deploy multiple RD Gateway servers for high availability/load balancing.

Install RD gateway server role and console from PowerShell, it does install NPS role as well

SSL Certificate Configuration

Now open RD gateway manager from administrative tools

From the above snap, we can see that we need to install a valid SSL certificate (publicly routed domain) from public CA and also need to configure NPS policies to control who and which internal resources can access through this RD Gateway server. I am using "Let's Encrypt" SSL certificates and there are multiple client utilities available to generate CSR and request certificates from Let's Encrypt. I have used Certify SSL Manager. You may use GetCert as well. 

My public domain name is exchangelabs.in and certificate common name is "rdgateway.exchangelabs.in". The server must be published on the Internet with the certificate common name only. Let's Encrypt does provide SSL certificates which are valid for 90 days. You need to renew certificates every three months. In fact, this can be automated.

Once a certificate is requested and installed on the server, from RD Gateway manager right-click the server in the left pane and click Properties

Click "Import certificates" under SSL certificates tab

Select one with Exchangelabs.in and click Import and click apply on the main property page

Certificate applied

NPS Policy Configuration

Since we wanted to use the NPS component on the same server for connection and resource authorization, we need to instruct the RD Gateway server to use the local server for same.

Next step is to create NPS policies (Connection Authorization Policy - CAP and Resource Authorization Policy - RAP)

From gateway manager, right-click policies and click "Create New authorization Policies"

Select the 1st option to create both policies in one shot and then click next

Name the CAP policy and then click next

Select the Password based authentication method and add AD users group which should be able to connect through this RD Gateway server. You may restrict which computers can connect through this RD Gateway server by specifying the client computers group in active directory. This will restrict access to specific domain-joined computers only from the Internet

On this page, define if the client local resources are allowed to map on the server being connected with RDP through this RD Gateway server

On this page, define the idle session timeout and session time out action

Review the summary and click Next

Give a name to RAP policy and then click Next

Add here are the same AD users group which we previously added under CAP section. These users can connect to internal server resources with RDP

On this page, specify the AD computers group / custom RD Gateway managed groups or allow users to connect to any network resource (computer). The difference between the two is that as with any network resource you can connect to workgroup servers as well. Make your selection and then click Next

By default, the RD Gateway server connects to internal servers over RDP port 3389. You can change this port, however, the same needs to be changed on the internal resource to be connected

The registry needs to be modified on internal resources for that as mentioned in this Microsoft article

View the Summary and then click Finish.

CAP and RAP policies created successfully. Click Close.

Server Transport Settings and SSL Bridging

With Windows 2012 and above, the RD Gateway server supports three types of transports: RPC over HTTP, HTTP, and UDP. However, UDP connection can be made only after the https tunnel is established. Windows RDP clients prior to Version 8 always connect to the RD Gateway with RPC over HTTP transport

Before publishing server to the Internet, make sure that the default TCP 443 and UDP 3391 inbound ports are configured under transport setting tab with RD Gateway server

The next step is to publish the RD Gateway server on the Internet. in my case, this is a VM hosted in Azure, so I got a public IP in Azure directly in NAT with a Gateway internal IP. Also, I have configured Network Security Group (NSG) in Azure which does allow TCP 443 and UDP 3391 inbound on RD Gateway server from the Internet. UDP connections are started with 2012 Server to improve RDP connection performance over poor Internet connections. 

The table below shows the required network ports and protocols for RD gateway functionality

In Azure we have directly published the RD Gateway server on the Internet. It is a direct NAT connection, hence I have not modified the RD gateway SSL bridging setting. The connections will be decrypted by the server itself.

However, if you are installing the RD Gateway server in a corporate network and the public IP is configured in the firewall, then it is recommended to bridge / offload the SSL connections in the firewall and depending on what you configure in the firewall, the RD gateway needs to be configured as shown below

Select the 1st radio button if the firewall is configured for SSL bridging - SSL bridging is a process where a security firewall device in DMZ decrypts SSL traffic, inspects the packets for safety, and then re-encrypts it before sending it on to the RD Gateway server. The RD Gateway server has to decrypt the traffic again. The server should have a powerful CPU if the connecting user base is more as it has to decrypt and process all connections

OR

Select the 2nd radio button if the firewall is configured for SSL offloading - SSL offloading is a process where the security firewall device in DMZ decrypts SSL traffic and sends unencrypted packets (http) to the RD Gateway server. Firewall to RD Gateway traffic remains unencrypted. This option keep server processor free as it does not need to process / decrypt connection requests

OR

If the firewall is configured with a pass through option, then do not use SSL Bridging. Firewall do not decrypt SSL traffic and encrypted connections will be terminated and decrypted on the RD Gateway server directly. That is what Azure did here as SSL traffic is directly forwarded to the RD Gateway server over IP NAT and port forwarding. The server should have a powerful CPU if connecting to the user base is more

DNS Configuration

Configure DNS records for the RD Gateway server with a public DNS

Also add with internal AD\DNS server

Client Connectivity

Now from the Internet client (RDP 10), we can test the connectivity to internal servers

From the external client machine, open the RDP client, navigate to the advanced tab and click on Settings. There, configure the RD Gateway server public FQDN as shown above. Also, select the last checkbox to forward Gateway credentials to the Internal server while connecting through RDP since both servers are part of the same AD domain.

Now type the internal server hostname followed by the internal ADDomain\username and click connect

When prompted, supply the credentials and click OK. Note that the user must be part of the AD group configured with NPS policy to allow connecting through the RD Gateway

With clients connected to the internal server seamlessly and securely, you can see and click the padlock in the connection status bar

You can now view the connected sessions, The HTTP and UDP connection is taken from the Windows 10 RDP client

The RPC HTTP connection is taken from the Windows 7 RDP client (7.1)

We can disconnect either user or connection. Disconnecting a user will disconnect all sessions initiated by him.

RD gateway load balancing and High Availability

The 2012 RD Gateway server supports hardware and software load balancing but does not support DNS round-robin based load balancing. The RD Gateway servers part of load balancing must be added to the RD Gateway farm as shown above.

DNS Round Robin load balancing is not supported because the server uses HTTP transport and this transport uses two HTTP channels (input and output) which must be routed to the same RD Gateway server. DNS Round Robin may not route both channels to the same server. However, hardware and software load balancers support IP / Cookie-based affinity ensures that both HTTP connections are routed to the same RD Gateway. Also, the UDP and HTTP connections may be handled by separate RD Gateway servers. Microsoft NLB can be used since it supports IP based affinity. Within Azure, you can use Azure software Load Balancers

I have covered most of standalone RD Gateway server aspects here and hope that you may find it useful.

If you have any comments to share about any of the information presented here, I encourage you to leave a comment below or Ask a Question to get help from myself and other highly talented experts at Experts Exchange.

Thank You.