Using an RDS Gateway to Connect to a Remote Lab

In my role I often have to demo solutions at conferences, customer locations, or training rooms. I prefer to travel with only my Surface Pro and a portable USB monitor (which I use for multi-mon) so I depend on the ability to remotely connect to either my Azure or home lab. In most cases I can connect into a wired, Wi-Fi, or LTE network with my Surface Pro and use that to connect to one of my labs. I have, however, been in situations where this wasn’t possible. In such cases the only option I have is to do the demo on an internet connected machine provided to me when I arrive onsite and hopefully use it to connect to one of my labs.

In this situation I usually don’t have admin rights to the workstation they give me and the network I am on blocks most outgoing ports, including port 3389, which prevents me from using standard RDP to connect. This means my only option is to connect over port 443 (SSL) using a trusted certificate or try and use a 3rd party solution which is not my preference. The reason I need a trusted certificate is because of lack of rights to install an untrusted certificate on the workstation provided and policy prevents the use of an untrusted connection. After hitting this I decided to upgrade my remote connectivity infrastructure in my Azure and home labs enabling me to be able to connect on almost any internet connected PC. Several of my peers asked me how I configured my labs so I figured this might also be useful for the community. I also want to point out that there are many different ways to configure this and the steps below are simply the route I took for my situation.

Configure DNS Records

  • Use a dynamic DNS service so you can connect to your home lab using a name. The service should have a client (which runs as a service) that you can install on your home systems so if your IP address changes it updates the DNS record. Some of these services are free if using their domain names but charge a small fee if you want your own domain name: If you are using Azure then this isn’t necessary unless you end up using a trusted certificate. If using a trusted certificate then create your own domain name.
    • For home labs, create an A record for your lab in general or for the machine you plan on using as an RDS Gateway. This is the name you’ll use to connect to your lab.
    • For Azure (using a trusted certificate), create a CNAME record that will re-direct to the machine you plan to use as your RDS gateway.

Configure Firewall (Home Lab Only)

  • Create port forwarding rules on your firewall to connect via RDP directly to your physical hosts. I do this only for my physical hosts and use random ports that forward to 3389 and you’ll need one rule for each machine. I use this so I can connect to my physical systems in case my RDS Gateway is down and I’m out of town.

Configure RDS Gateway

  • Spin up a machine (VM) running Windows Server 2012 R2 that will be a Domain Controller or domain joined and used as your RDS Gateway. Make sure you install Active Directory or join this machine to a domain. Also make sure that applicable ports are opened on the Windows Firewall if you’re using it.
  • Create a port forwarding rule on your firewall for port 443 to port 443 on the machine you will use as an RDS Gateway. If using Azure you do this by configuring an endpoint.
  • Add the RDS Gateway Role
    • Add a new role, select Role-based installation, and click Next
    • Select Remote Desktop Gateway, and click through the wizard
  • Add the certificate
    • Install a certificate. I used a trusted wildcard certificate and a tool provided by the certificate company for this: If you don’t want to use a trusted certificate you can create one using a certificate server and use that as well but you’ll want to also install that certificate on the machine you’ll be using to connect to the RDS Gateway.
    • I specified * as the common name to generate the certificate and then installed it on the RDS Gateway server.
    • In Administrative Tool\Remote Desktop Services, open the Remote Desktop Gateway Manager
      • Right-click on the RDS server, properties
      • Click the SSL Certificate tab and select the certificate, click OK
  • Create New Authorization Policies
    • Under Policies, Click Create New Authorization Policies
    • Select Create a RD CAP and a RD RAP policies, click Next
    • Name the policy
    • Choose <yourADdomain>\Domain Users for the user group membership, Click Next
    • Click Next on Device Redirection
    • Click Next on Session Timeout
    • Click Next on RD CAP Summary
    • Name the policy
    • Choose <yourADdomain>\Domain Users for the user group membership, Click Next
    • Choose Allow users to connect to any network resource, Click Next
    • Click Next on Allowed Port
    • Click Finish

Configure Environment

  • I prefer to disable or rename local and domain accounts named Administrator on all my VMs
  • Ensure Remote Desktop on all machines is enabled and check "Allow connections only from computers running Remote Desktop with Network Level Authentication (recommended)"

Test the Standard RDP Connection

Use this to make sure you can connect to your physical hosts bypassing the RDS Gateway. If the port forwarding rules are configured properly it should forward the random port you chose to 3389 on one of your physical hosts.

  • Open mstsc.exe
  • Connect to YourPublicRDSGatewayName:PortOfOneOfYourHosts

Test the RDP Connection over SSL

This connection will go to your RDS Gateway first, then connect to the machine you specified over 3389.

  • Open mstsc.exe
  • Click on “Show Options”
  • Go to the Advanced Tab and click on “Settings”
  • Select “Use these RD Gateway server settings” and put in your RDS Gateway server public name


  • Click “OK”
  • Go back to the “General” tab and put in the local name of the server in your lab you want to connect to


  • Click “Connect”
  • You should get prompted for credentials twice, once for the RDS Gateway and once for the machine you’re trying to connect to
Comments (0)

Skip to main content