Configuring Windows Server 2008 R2 RD Gateway for external access

Many of you know what RD Gateway is, but for those that don’t I’ll try to explain using a short version. RD Gateway is a Windows Server 2008 R2 role that gives administrators the power to allow users to connect using Remote Desktop Protocol to internal servers/workstations without opening to many ports in their firewall(s). The only port an administrator needs to open is 443, which is the port SSL is using. You can find the explained long version here. So for example if you have ten users that need remote desktop access you don’t have to customize ports any more; you know…user 1 connects to, user2 connect to and so on. All you have to do is create a CNAME or A record on your public DNS server that points to your RD Gateway server, or the public address of your firewall.

For this lab I have a Domain Controller, a RD Gateway Server, a RD Session Host server (it can be a simple server that supports more than one RD connection), and an external client running Windows 7. All servers are running Windows Server 2008 R2 SP1, and are joined to the domain If your internal domain name (eg: vkernel.local) differs from the external one, it will be a bit of a headache to configure the RD gateway, and maybe I will write an article in the future about this, but right now we’ll just stick with one domain which is also a public one. An Internal Enterprise Root CA is used to issue certificates in this lab, is just cheaper. The external client has the root certificate installed on the local machine Trusted Root Certificates Store, but if you have a lot of external clients I recommend you purchase a commercial certificate. Before we get started, I want to mention that the server names are very important, because those names are used on your external DNS server. You will understand what I mean as we go along.

First we need to request and install a certificate on the RD Gateway server, or the connection will not be established. If the Common Name in the certificate is different from the computer name (RD Gateway server) you will get an error message and the connection will be discarded.

To get rid of this message and be able to connect, when you request the certificate make sure you use the RD Gateway server name in the Common Name field of the certificate. In my case, my RD Gateway server in called “”, so my Common Name field in the certificate is the same.

This is not over, there is still one more thing about the RD Gateway name, at the client side. When you type the RD Gateway name in the server settings field on the RD client you need to type the name of the RD Gateway server that is also found in the certificate.

Did I confused you enough? Good, because there is more to come. Now you might say, but what if I don’t want to use the RD Gateway server name for clients to connect ? Some server names are too long or too complicated, and I don’t want my users to type in the RD client something like this “”. I hear you, and the solution is to use a SAN certificate, but I’ll stress this again, even if you use a SAN certificate that RD Gateway server name needs to be present in the SAN attribute field or the Common Name field of the certificate or the connection will be dropped. Now let’s request that certificate so we can assigned it to the RD Gateway server. Open the Certificate Store by using the Run command and typing mmc.exe.

Go to File > Add/Remove Snap-in, click Certificates then the Add button.  Choose Computer account > Local computer.

Right click the Personal folder and choose All tasks > Request New Certificate.

Since we have an Active Directory infrastructure here, we are going with Active Directory Enrollment Policy, so leave the default selection and press Next to continue.

Check the Computer box and click Enroll.

Click Finish to close the Certificate Enrollment wizard.

The certificate is in our Certificates Store ready to be installed on the RD Gateway server.

Log on to the RD Gateway server, go to Start > Administrative Tools > Remote Desktop Services > Remote Desktop Gateway Manager. Once the console is opened right-click the server and choose Properties.

Go to the SSL Certificate tab, choose the second option “Select an existing certificate from the RD Gateway Certificates …” then click the Import Certificate button.

Select the certificate from the list and click Import. This is the certificate we just requested from our internal CA.

As you can see some certificate details are displayed on the SSL Certificates tab after the import. Click OK to close the server Properties.

The RD Gateway Manager Console should now look like this.

The next step is to create the A records on our public DNS zone, so clients know where is the IP address for and for Never mentioned the RDHost before, but this is my RD Session host server where clients connect and open their RD sessions. So log on to your cPannel or whatever administration console you have for your domain, and go to the DNS Zone Editor.

On the name box under Add an A Record, type the FQDN of you RD Gateway server, then the IP address where the server can be found. When done hit the Add a Record button to create the entry. Do the same for your RD Session host server.


Our RD Gateway server is in place and configured, so are our DNS records. The only step left is to do open the port 443 on the firewall. Since there are thousands of models out there I can’t show you all, so I will leave this to you. If you have a router and the RD Gateway and RD Host servers are behind this router you will need to forward port 443 to the RD Gateway server from the outside world. When this is complete go to one of your external clients and open the RD client console (Start > Run > mstsc). Expand the console by clicking the Options button, then go to the Advanced tab and click the Settings button.

Select Use this RD Gateway server settings radio button and in the Server name box type the FQDN of your RD Gateway server; mine is Now clear the box Bypass RD Gateway server for local addresses, because you can have connections problems with this as you can read here. Click OK when you’re done.

On the General tab type the RD Session Host server name in the Computer box; mine is Click Connect.

Type the log on credentials and click OK.

By now you should get a certificate warning from your RD Session Host server, and this is because the certificate on this server is self signed; in my case anyway. To get rid of this warning you need to replace the self signed certificate on the RD Session Host server with one issued from the internal CA. Read here to see how is done, but for now click Yes to continue.

And now you should have a RD connection made trough a RD Gateway server. You can check that by clicking the Connection Properties icon from the RD bar.

Want content like this delivered right to your

email inbox?

12 thoughts on “Configuring Windows Server 2008 R2 RD Gateway for external access

  • 21/08/2013 at 17:05

    I have a certificate problem in my rds setup

    certificates used:
    RDS san certificate from internal CA farmname.internal.local
    Thahwte public wildcard cert *

    Fields of self created SAN certificate:
    Certificate Key usage: (
    APP_Policies: server authentication, code signing
    Subject Alternative Name: DNS Name=internal.local
    DNS Name=*
    Certficate Template Name: WebServer
    Friendly Name: RDS.internal.local
    Description: San Certificate

    I have created a four server RDS Farm
    RDS1.inretnal.local session host
    RDS2.internal.local session host
    RDSWEBGW.internal.local RDS web & GW role
    RDSCB.internal.local RDS Connection Broker

    It is a 2012 setup with the following certificates tied to the roles
    RD Connection broker – SSO RDS san cert
    RD Connection broker -Pub RDS san cert
    RDWeb Access public wildcard cert
    RD Gateway public wildcard cert

    Installed theSAN certificate on the rds host in personal certificates and tied it’s tumbprint to:
    rootcimv2 erminalservices -Filter “TerminalName=’RDP-tcp'”

    when we connect on the external adress i get a Name mismatch error:
    requested remote computer =*.local
    name in certificate =*

    I can see the public wildcard certificate is being used. Do i have to split the roles of web access an Gateway server to get a working setup? The deploynemt wizard tells me that since i’m using both roles on one server i need to use the same certificate. Where i feel the RD Gateway needs to be changed to the san certificate.

    Is there someone tohat can help me out with this?

    • 27/08/2013 at 08:45


      The certificate you are using on your RD Gateway needs to have the FQDN of this server. So basically you need two names in this certificate, the external FQDN which clients use to connect from the internet, and the internal FQDN of your server.

      Internal domain – vkernel.local
      Internal RD Gateway FQDN – Gate.vkernel.local
      External domain –
      External RD Gateway address – (this is set on your public DNS)
      Certificate (SAN) – gate.vkernel.local &

      Let me know how it works.

  • 15/05/2013 at 17:44

    I’m sorry Adrian
    i’m backup to you because i’m very confused about certificate side.
    According to what you suggested I’ve just obtained a personal certificate from StartSSL but is Class1 cert, so as far as i know it is not good to use on a web server.
    Class 2 certs are not free from StarSSL and i’ve just need to make some testing here before get in production and hence obtain a real and correct Class2 cert for the target organization.
    By the way, the organization has its own and i would like to use as DNS for client connections. May i use SAN cert for this purspose right? if so i still do add the correct A and CNAME records in the DNS of the main domain to point to the public IP of the RD gateway? Sorry for the confusion.


    • 16/05/2013 at 15:12

      You may use a SAN certificate, but make sure the RD Gateway computer name is in the certificate attributes. Any other domain or subdomain clients will use to connect needs to be in the certificate. Cheers…

  • 10/05/2013 at 16:05

    Hi Adrian,

    I Agree with your analysis.

    The issue is the fact that VMware Workstaton 8 is not allowing the external computer to see the CA on the RD Gateway. The certificate that the external computer sees is a VMware CA and not the RD Gateway CA

    Any ideas on how to resolve this issue?

    Thank you

    • 15/05/2013 at 12:57

      You maybe setup the network wrong in VMware Workstation. I don’t know what the VMware CA is. The external client doesn’t need to see the internal CA, all you have to do is import the root certificate from your internal CA to the external client.

  • 10/05/2013 at 07:48

    Hi Adrian,

    This is a very good Blog. Thank you.

    Here is my issue:

    I am testing a small Win 2012 Network made up from 3 VM hosted on a VMware Workstation 8.

    The DC is on
    The Terminal Server is at
    The RD Gateway, RD Connection Broker, RD Web Access, RD Session Host are installed on the Terminal Server.

    I created a Self Signed Certificate using the old Microsoft SelfSSL Utility and imported it into RD Connection Broker, RD Web and RD Gateway.

    The Certificate CN=TSRV1.Domain.Loc
    The Certificates expires on 9/23/2040

    I Imported the Certificate into the Host Computer.

    I can establish an RDC session using RD Gateway from the DC to the Terminal Server over the Virtual LAN.

    On the HOSTS file on the Host Workstation I mapped the local TSRV1.Domain.Loc to ( the IP address of the Host)

    I can establish an RDC session from the Host to the Terminal Server or from a second external Win 8 PC if a do not use RD Gateway Using the computer address TSRV1.Domain.Loc:9996 ( Port 9996 is forwarded to the Terminal server Port TCO 443 and UDP 3391)

    However if I try to use RDC with the RD Gateway from the Host or a second Physical Computer I encounter an error that sais:

    “This computer can’t verify the identity of the RD Gateway. TSRV1.Domain.Loc Its not safe to connect …”

    When I view the Certificate instead of displaying the RD Gateway Certificate that I Installed it is displaying a certificate issued to VMware by VMware.

    Any ideas how to resolve this issue?

    Thank you,

    • 10/05/2013 at 09:55


      The certificate is the problem there. The certificate that is installed on the RD Gateway needs to be trusted by external clients. I recommend you install an Internal CA, and import the root certificate from the CA on your external clients.
      Second, the name of the server (the RD Gateway server) needs to be present in the certificate attribute, even if its with a .local domain. If that’s the case you will need an SAN certificate because you need to include the server name (with the .local extension) and the public name that clients are using to connect.

  • 28/02/2013 at 18:09

    i’m trying to get this setup working to no avail… ;-(
    I’m using W2008 R2 to latest patch level, Enterprise CA installed and properly configured, SAN cert (V3) correctly installed in both RD Gateway and IIS.
    Both RD gateway and RD host are on the same server and i’m trying to connect from the external internet with a Windows 7 client.
    I carefully followed (at least i think) the instructions in this howto regarding the CN fields in SAN cert. I’ve a internal generated V3 SAN cert like this:

    Alt subject:
    Alt subject: DNS=NETBIOS.localdomain.local

    Port 443 is reachable from the external.
    I’ve than configured a RemoteApp rdp files on the W2008 R2 and copied it in the windows 7 client in order to test the connection.

    This rdp files points to the exactly same CN configured in the SAN cert so to and i’ve also provide a public DNS pointing to the machine.

    When i try to connect i get the initial message from RD gateway telling me to loging with the credentials for both the RD gateway and the remote computer (RD host on port 3389).

    After few seconds, i always got the annoying message the tells me that is impossibile to verify the identity of the remote gateway computer (

    If i open the cert presented from the remote gateway, i can see that is the correct one ( but the connection drops.

    Help please.
    This is driving me crazy!


    • 28/02/2013 at 20:57

      Since you are connecting from outside your network you need to have a proper certificate form an public CA (use StartSSL, is free). If you use the certificate issued from your internal CA it might work, but not always; it depends on the CRL expiration date. It will definitely work with an internal CA certificate if you have an OCSP responder; but this is too advanced and complicated for a small network.
      Second…as you can see in the post I’m using a public domain to connect, so you need to have a public DNS name too then create an A record that points to your external IP (use your RD host name for the record), then create a CNAME record that point to your A record created previously (use your RD Gateway name for the record).
      If this two things are not handled, you are out of luck. Let me know how it works.

      • 15/05/2013 at 11:22

        Hello Adrian,
        regard the DNS part, i’ve have mapped the public IP of the network with DynDns.
        Is this correct?
        It is not clear to me where to create the A and CNAME records you’ve mentioned.

        For the rest i’ve just setup an SSL cert with StartSSL and i’ll let you know soon if this sorted out.


        • 15/05/2013 at 13:03

          The A record and the CNAME record need to be created on your public DNS servers. The names you type when you create those records need to be resolvable in internet.


Leave a Reply

Your email address will not be published. Required fields are marked *