RD Gateway deployment in a perimeter network & Firewall rules

RD Gateway deployment in a perimeter network & Firewall rules

Rate This
  • Comments 31

 

Remote Desktop Gateway (RD Gateway) is a role service available in Windows Server 2008 and higher versions. It allows authenticated and authorized remote users to securely connect to resources on an internal corporate or private network over the Internet. RD Gateway encapsulates Remote Desktop Protocol (RDP) within RPC, within HTTP over a Secure Sockets Layer (SSL) connection. RD Gateway server is exposed to the Internet (an untrusted network) and because of the reasons discussed in the Perimeter network section, either RD Gateway server is deployed in the perimeter network or RD Gateway server is deployed in the internal network with an ISA server in the perimeter network.

1. Perimeter network:

A perimeter network (also known as a DMZ, demilitarized zone, or screened subnet) is a small network that is set up separately from an organization's private network and the Internet. In a network, the hosts most vulnerable to attack are those that provide services to users outside of the LAN, such as e-mail, web, RD Gateway, RD Web Access and DNS servers. Because of the increased potential of these hosts being compromised, they are placed into their own sub-network called a perimeter network in order to protect the rest of the network if an intruder were to succeed. Hosts in the perimeter network should not be able to establish communication directly with any other host in the internal network, though communication with other hosts in the perimeter network and to the external network is allowed. This allows hosts in the perimeter network to provide services to both the internal and external network, while an intervening firewall controls the traffic between the perimeter network servers and the internal network clients.

2. Perimeter network designs:

Typically, a perimeter network can be designed and deployed in one of the following ways:

  • Single firewall (three-homed perimeter network)
  • Dual firewall

2.1 Single-firewall perimeter network:

In a single firewall perimeter network the firewall has 3 network adapters:

  • The first network adapter connects to the internal corporate network.
  • The second network adapter connects to the perimeter network.
  • The third network adapter connects to the external network (Internet).

clip_image002

Figure 1: Single firewall perimeter network with RD Gateway server in the perimeter network

2.2 Dual firewall perimeter network:

In a dual firewall perimeter network, a firewall is located on either side of the perimeter network. One firewall is connected to the external network, one firewall is connected to the internal network, and the perimeter network resides between the two firewalls. This is a more secure approach because an attacker has to break both firewalls in order to get to the internal network.

clip_image004

Figure 2: Dual firewall perimeter network with RD Gateway server in the perimeter network

3. AD DS models in perimeter network

Following are the possible AD DS models that are suitable for RD Gateway:

  • No AD DS in perimeter network: There is no AD in the perimeter network and RD Gateway (in the perimeter network) is joined to the internal network domain.
  • Forest trust model: One-way trust between the perimeter network AD DS and the internal network AD DS. RD Gateway is joined to perimeter AD DS.
  • Extended corporate forest model: A read-only domain controller for the internal network forest is in the perimeter network, and RD Gateway is joined to the internal network domain.

3.1. RD Gateway without AD DS in perimeter network deployment:

When there is no AD DS in the perimeter network, ideally the servers in the perimeter network should be in a workgroup, but the RD Gateway server has to be domain-joined because it has to authenticate and authorize corporate domain users and resources.

The following diagram shows the traffic flow from the Internet to the perimeter network and from the perimeter network to the internal network in this deployment.

clip_image006

Figure 3: Traffic flow from Internet to perimeter network and from perimeter to Internal network

3.1.1. Internal firewall ports:

In this deployment, RD Gateway needs the ports to be opened on the internal firewall for the following purposes:

3.2. RD Gateway with forest trust model deployment:

In this deployment, there is AD DS in the perimeter network which trusts the internal network forest to authenticate the internal network forest users in the perimeter forest domain. RD Gateway is joined to the perimeter network domain. The trust between the perimeter network forest and the internal network forest is one-way, so configuring RD Gateway to use a central NPS server which is in the internal network is required in this deployment.

The following diagram shows the traffic flow from the Internet to the perimeter network and from the perimeter network to the internal network in this deployment.

clip_image008

Figure 4: Traffic flow from Internet to perimeter network and from perimeter to internal network

3.2.1. Internal firewall ports:

In this deployment, RD Gateway needs the ports to be opened on the internal firewall for the following purposes:

3.3. RD Gateway with extended corporate forest model:

In this deployment, there is a read-only domain controller (RODC) in the perimeter network for the internal network forest. RD Gateway is joined to the internal network domain and talks to RODC for authentication and authorization purposes.

The following diagram shows the traffic flow from the Internet to the perimeter network and from the perimeter network to the internal network in this deployment.

clip_image010

Figure 5: Traffic flow from Internet to perimeter network and from perimeter to internal network

3.3.1. Internal firewall ports:

In this deployment, RD Gateway needs the ports to be opened on the internal firewall for the following purposes:

4. Firewall rule configurations required when RD Gateway is in the perimeter network:

4.1. Firewall rules for the path between the external network and the perimeter network (Ports that need to be opened on the external firewall):

  • Port TCP:443 should be opened for allowing HTTPS traffic from the client sitting on the Internet to the RD Gateway server in the perimeter network.

4.2. Firewall rules for the path between the perimeter network and the internal network (Ports that need to be opened on the internal firewall):

The internal firewall should allow all communication from the RD Gateway server to internal network resources. Here are the ports that need to be opened on the internal firewall when the corresponding traffic (DNS, RADIUDS, RD Gateway Authentication, etc.) destination point is in the internal network.

RD Gateway authentication traffic:

Firewall rules between the perimeter network (RD Gateway) and the internal network (Domain Controller) to authenticate the user:

  • Server Protocol = Kerberos
  • Port = TCP: 88

The RD Gateway server talks to the NT Directory Service (NTDS) RPC service on AD. The NTDS RPC service listens on an unused high end port. RD Gateway does not know the port number on which NTDS RPC service is listening. So RD Gateway talks to RPC Endpoint Mapper which listens on a constant port and gets the NTDS RPC service port number. Finally it makes a connection to the NTDS RPC service. Fortunately, the Admin can make the NTDS RPC service on AD listen on a constant port by using a registry key. To learn how to configure the registry values on AD for NTDS RPC service ports, see this article .

  • Server Protocol = RPC Endpoint Mapper
  • Port = TCP: 135, TCP: <Port on which NTDS RPC service listens on AD>

Note: In Windows Server 2008 R2, RD Gateway can be configured to use non-native authentication methods through a custom authentication plug-in. If RD Gateway is configured with a custom authentication plug-in, contact the vendor of the authentication plug-in to find out which firewall rules are required for RD Gateway authentication.

RD Gateway authorization traffic:

Firewall rules between the perimeter network (RD Gateway) and the internal network (domain controller) to authorize the user:

  • Server Protocol = LDAP
  • For LDAP: Port = TCP: 389, UDP: 389

Note: In Windows Server 2008 R2, RD Gateway can be configured to use non-native authorization methods through a custom authorization plug-in. If RD Gateway is configured with a custom authorization plug-in, contact the vendor of the authorization plug-in to find out which firewall rules are required for the RD Gateway authorization.

DNS traffic:

Firewall rules between the perimeter network and the internal network to resolve the internal network resources:

  • Server Protocol = DNS
  • Port = TCP: 53, UDP: 53

RDP traffic:

Firewall rules between the perimeter network and the internal network to forward RDP packets from client:

  • Server Protocol = RDP
  • Port = TCP: 3389

Certificate Revocation List traffic:

Firewall rules between the perimeter network and the internal network to contact CRL distribution point to get the certificate revocation list:

  • Server Protocol = LDAP or HTTP or FTP
  • For LDAP: port = TCP: 389, UDP: 389. For HTTP: port = 80. For FTP: Port = 21

Note: The Certificate Revocation List is needed either to validate the client certificate during smart card authentication or when the certificate deployed on RD Gateway is an enterprise/standalone CA certificate. To know which protocol is needed to contact the CRL distribution point for a certificate, open the certificate and go to the Details tab and look at the CRL Distribution Points field.

RADIUS traffic:

If RD Gateway is configured to use a central server running NPS and if the NPS server is not in the perimeter network, then the following additional firewall rules are needed between the perimeter network (RD Gateway) and the internal network (NPS Server).

  • Server Protocol: RADIUS
  • Port = UDP: 1812
  • Server Protocol: RADIUS Accounting
  • Port = UDP: 1813

5. RD Web Access and RD Gateway on the same server:

If RD Web Access and RD Gateway are on the same server in the perimeter network or when RD Web Access is in the perimeter network, the following additional firewall rules need to be configured between the perimeter network (RD Web Access) and the internal network (RemoteApp Server).

RD Web Access points to single RD Server or Single RD Server farm:

This scenario is possible in Windows Server 2008 or higher versions. The WMI service on RD Server listens on an available high end port. The port on which WMI service listens can be fixed by executing the commands specified in this MSDN article. This fixed WMI port needs to be opened on the firewall.

  • Server Protocol: WMI
  • Port = TCP: <WMI Fixed Port>

RD Web Access points to multiple RD Servers/farms:

This scenario is possible in Windows Server 2008 R2. The WMI service on RD Web Access Server listens on an available high end port. The port on which WMI service listens can be fixed by executing the commands specified in this MSDN article. This fixed WMI port needs to be opened on the firewall.

  • Server Protocol: WMI
  • Port = TCP: <WMI Fixed Port>

RD Web Access points to a centralized publishing server (Connection Broker):

This scenario is possible in Windows Server 2008 R2.

  • Server Protocol = RPC
  • Port = TCP: 5504

Note: If there is an ISA server already deployed in the perimeter network of your organization, then RD Gateway server can be put in the internal network which reduces the number of ports that need to be opened on the internal firewall (path from perimeter network to internal network) to one. Also, in order to ensure that un-authenticated traffic does not reach the RD Gateway server (i.e. the internal network), you can pre-authenticate the HTTPS traffic reaching the ISA using One-time-Password (OTP) – a form of RSA SecureID. More information on how to configure ISA can be found in the RD Gateway step-by-step guide.

If authentication is not enabled on ISA, the following is the firewall configuration requirement in RD Gateway (internal network)-ISA (perimeter network) scenario.

  • If ISA is used as HTTPS-HTTPS bridging device:
    • Ports to be opened in the external firewall : TCP:443
    • Ports to be opened in the internal firewall: TCP: 443
  • If ISA is used as HTTPS-HTTP bridging device:
    • Ports to be opened in the external firewall: TCP:443
    • Ports to be opened in the internal firewall: TCP:80

If authentication is enabled on ISA, then depending on the ISA authentication method some additional firewall rules may be needed.

Useful Links

Leave a Comment
  • Please add 4 and 4 and type the answer here:
  • Post
  • hi,

    i've a customer specifically asking for not joining the RD Gateway server to an AD DS as he doesn't want to deploy AD DS in the DMZ and do not want to allow AD DS traffic from DMZ to Internal Network due to security reasons.

    I've seen that the RD Gateway allows a remote NPS Server to be used for Authorization - would it be possible to have the RD Gateway in a Workgroup and use a Remote NPS Server in the Internal Network used for AUTH? this would be a much better solution and preferred by my customer. Any idea if this would work? (or a reason it wouldn't?)

    BG Christoph

  • Hi,

    As of today RD Gateway does not support RADIUS authentication, that you are talking about.

    Today RD Gatewway has to be domain joined to authenticate and authorize the users.

    If Admins do want to keep RD Gateway server which is domain joined in DMZ, then the the only available solution to have ISA server in DMZ and RD Gateway in internal network.

    Regards,

    Rajesh.

  • Hey Cristoph,

    Just wanted to add to this by saying that NPS is only used to store Connection Authorization Policies. NPS doesn't handle your Resource Authorization Policies. That's a local XML file. If you want to use AD security groups to control what internal resources your connecting clients have access to you're out of luck in the suggested scenario.  

    Truthfully, putting your TSG\RDG server internal is the best way to go.  It's very secure based on the encapsulated 443 traffic (RPC over HTTP) and there are many documents on setting up TSG\RDG with ISA firewall servers.  These can be translated through to other firewalls as well of course.

    Best of luck!  

    Best regards,

    Brett

    Microsoft Support Escalation Engineer      

  • Hi,

    RD Gateway is not supported in one-way forest trust AD DS model. This is because RD Gateway wont be able to check for user group membership in RAP. Hence one gets a RAP failure with domain user.

  • Hello all,

    TS or RD-Gateway deploying to internal network is not a solution it is a problem, and this problem cannot be solved in the moment. If you put in the DMZ, you need to open the firewall for AD-traffic an more, if you put it into the internal network, you will have your honeypot inside, which disagrees all secure DMZ-design.

    I do not know, why RD/Server-devolping team didn't take a look to OCS or Exchange-Team. The implementet a server-edge component with no need of being a memberserver. Why not implementing AD-querys over https ?!

    Regards Timo

  • We use RSA Security SecurID and it acts as a radius server.  Is there any way to use our SecurID tokens with the Gateway?  We would also require AD authentication as well.

  • It was my impression that the RD gateway (from 2008 R2) could be placed internally in a network and wouldn't need to be in a DMZ since it can bypass firewalls. Why go to the trouble of putting it in a DMZ and reconfiguring firewalls? If that is the case the whole R2 advantage is pointless.

    Also, just a comment for the guys working on the installer. The install documents are vague about the need for AD. If you install it on a workgroup computer it won't even check if the computer is in a workgroup, it'll run through the install then fail. It wouldn't be too hard to check this and warn you.

  • It has always been a security best practice to put SSL Reverse Proxy services in a DMZ.  This is done so no ports are opened from the public Internet to the corporate network, but rather SSL traffic is terminated in the DMZ where a known trusted host proxied communications to the corporate network.

    The change in R2 is that the RDS Gateway doesn't need to be a domain member.  This was a problem in 2008, as customers (for good reason) didn't want to open AD communication between the corporate network and DMZ.

    This placement of such devices in DMZ is standard practice by almost every company I've encountered.  It's easy to configure once you've done it.

  • So, after all, what is the most secure architecture for RDS Win Serv2008?

    Should RDS Web Access and RDS GW be placed in DMZ and in workgroup?

    How do remote user can perform domain authentication? How SSO works in this case?

  • Patrick, considering that R2 does things differently and one of the main points MS mentions about R2's RD Gateway is that it can sit behind a firewall it seems like exposing the RD Gateway in a DMZ isn't as secure as the old way. Plus, for small companies they don't have to go to the expense of having a machine sit in the DMZ that does nothing but act as a RD Gateway. Wouldn't it be more secure to set this RD Gateway box behind your main firewall and do away with all the DMZ hassle mentioned here? (Remember, I'm talking about the new R2, not the older way).

    If nothing else I think a section should be added to this article describing how you'd place an R2 RD gateway behind your main firewall and still have people access from the outside world. I'm a little confused by how this is done as far as what ports to open (they imply you don't need to open any since https is normally open anyway) or how a remote computer can access the RD Gateway if it's hidden behind a firewall.(they say you can do it but never seem to indicate how).

  • Anyone find information about placing the 2008-R2 Remote Desktop internally and accessing it externally (no DMZ)? I was attracted to this new feature since you can use this without a VPN or DMZ but so far I haven't found any info on it. All the information talks about deploying and using it internally, which is pretty simple. The older info describes using it through a DMZ if you need external access. The new information indicates you can now use HTTPS to access it externally but there is no information on how this is done. They imply the firewall and NAT don't get in the way but I fail to understand how you can access an internal machine from the outside without opening ports (obviously I'm not a firewall guy). The whole "use this rather than VPN" doesn't seem easier if you have to use a DMZ, reconfigure firewalls etc.

  • Hi,

    no chance, the concept of placing a RD-Gateway into the DMZ is not good, even under R2. You have two possiblities. a. Place RD-GW in DMZ as Mebmberserver and open a bunch of ports. b. Place RD-GW in DMZ as standalone server and define only local RAPs and CAPs no AD-Based.

    But two answer your question, you need a Reverseproxy like Forefront Threatmanagement Gateway (foremely ISA-Server), so you can terminate https on the Forefront Gateway in the DMZ and from the Forefront Gateway you build a https connection to the RD-Gateway behind the firewall (so inside) that is called a honeypot. With Forefront Threatmanagement Gateway you can also secure your email-traffic and so on.

    You have no other chance, the RD-GW was really not good desigend, there are some more things, if you are intrested give me a note.

    Regards Timo

  • Timo,

    thank you for "opening my eyes" about "simplicity" of RDG.

    We are small company and I wanted to redisign our remote access shema. Presently TS2003 accessed through VPN.

    I tested RDSH and RDWEB internally. The management liked published apps and option to add remote desktop access to RDWEB.

    So, the last part is to make it work to outside users.

    I was exited :) to read and see the pictures provided in first part but after reading whole discussion and your's "the RD-GW was really not good desigend" I am a bit frustrated...

    I read a year ago that combination of TSG 2008 and TSWeb provides secure remote access to internal resources without complexity. Even SSL port is usually opened :)

    Now, I see that to make it properly configured you need DMZ, ISA and good knowledge. The last one we always need :)

    May be it is a naive question after all what was told above but I want to ask.

    What will happen if RDG will be placed on LAN and only SSL port will be opened to it?

    Would the security will be seriously compromised?

    Presently, we have Exchange server on LAN. The only ports that are opened on firewall are for SMTP and HTTPS. I know many companies do it this way. DMZ with another host and etc is not really an option.

    What you can recommend if we want to implement

    RD2008r2 - RDSH,RDWEB,RDG on LAN without using DMZ. We can add OTP...

    If you will say no way to make it secure I will just forget this whole idea until Server 2013 will bring promised security and simplicity :)

    From my previous reagings I got the impression that people using RDG without problem. DMZ wasn't mentioned. Just certificates. And I thought that certificate on client secure the connection.

    Sorry, for a long post. It is the first time that I found all details about RDG.

    Thanks,

    Michael.

  • @Michael

    As discussed in the blog, you can choose to put your Gateway server in either of the following configuration:

    1. In the internal network: In this case we recommend using an ISA server in the front to pre-authenticate the traffic reaching your internal network and hence is pretty safe.

    2. In the DMZ: In this case you can put the RD Gateway server in the DMZ and join it to the DMZ domain. The firewall ports that you need to open in this case are for traffic flowing only between the DMZ domain and the internal domain and hence not like opening the firewall ports to the external world and hence should not be a concern.

    Hope this will reduce your concerns and you should be able to use RD Gateway in a easy and secured way.

  • Placing an RD Gateway in the DMZ and making it a Domain Member blows my mind from a design perspective.  Relying on ISA as the only way to provide a more secure path to AD seems like a cop out from the design perspective.  Can ANYONE tell me how I might put the RDG in the DMZ in a workgroup, and make it work.  I want ONLY non domain users to access the TS from the outside.  Why isn't this scenario possible?

Page 1 of 3 (31 items) 123