Recommended network topology for exposing RemoteApp programs via TS Gateway
I am running Remote Desktop Services on the Windows Server 2008 R2 platform.
What is the recommended network topology for exposing RemoteApp programs via TS Gateway from untrusted networks? Note that client users are authenticated against the domain in which the RemoteApp server is located. Note also that I am not planning to use RD WebAccess.
I have seen two different recommendations so far: 1) Place the RD Gateway server in a DMZ, and pass the RDP packets through to the RemoteApp server; and 2) place the RD Gateway server on the same network as the RemoteApp server, use a Layer 7 firewall (or a similar solution) in the DMZ to filter out malicious packets and then pass the acceptable http or https packets onto the RD Gateway.
What are the recommended network topologies (if more than one), and what are the pros and cons of each?
Thanks.
Answers
- 1) Pro: The simplest setup. It is also the setup that MS more or less recommends from the RDG documentation.
Con : Exposes the server directly to the Internet and makes it highly vulnerable. Also, while I'm not so pessimistic, I know some network security officers who are absolutely paranoid about directly exposing any MS OS to the Internet. You'll also need additional software, such as firewalls and ipsec policy running to truly secure it (unless this is already all done via a firewall in your dmz).
2) Pro : Setting up and testing is quite easy since they're both on the same network.
Cons : It will prolly require extensive testing to ensure that legit programs are not being blocked.
Big CON to both : The biggest con I can see to both though is that they only protect your network from direct attack. It will stop the RDG from being hacked, but neither solution does anything about the client. So in both models, if the client gets hacked, they can potentially see and/or take control of the app you are hosting.
Solution : use something similar to Cisco Secure Desktop. It establishes a VPN connection that doesn't require a client to be installed, and you can control access much more aggressively. Furthermore it will generally completely drop the connection if it detects a "hiccup". This could be a legit client hiccup caused literally by something as uncontrollable as the client's DSL line suddenly vibrating due to too strong winds, or it could be an actual hack attempt.
I don't know if this would be feasible for you though.
If not, I would go with Option 2.- Marked As Answer byMatthew Theobald Friday, November 06, 2009 10:02 AM
Hello Matthew,
Thanks for your feedback.
If you want a simple topology with one RD Gateway and one Session Host/RemoteApp, there is no more topology options. Generally, as J2 mentioned, we set up the RD Gateway inside the network and protected by the firewall, because RD Gateway contains some credential information and policy settings (RAP and CAP), exposing the server in DMZ environment could cause security risks. Instead, if you use RD Web Access to publish the RemoteApp programs, the Web server can be located in the DMZ because no critical information is stored.
If you want to improve the topology by enhancing availability, you could consider to setup a RD Connection Broker role to supply load balancing and reconnection features.
For related information, please refer to:
Deploying Remote Desktop Web Access with Remote Desktop Connection Broker Step-by-Step Guide
http://technet.microsoft.com/en-us/library/dd883258(WS.10).aspx
and
Deploying RemoteApp Programs to the Start Menu by Using RemoteApp and Desktop Connection Step-by-Step Guide
http://technet.microsoft.com/en-us/library/dd772639(WS.10).aspx
Hope the information helps. Thanks for your cooperation and patience, Matthew.
· Lionel Chen
TechNet Subscriber Support in forum
If you have any feedback on our support, please contact tngfd@microsoft.com
- Marked As Answer byMatthew Theobald Friday, November 06, 2009 10:03 AM
All Replies
- 1) Pro: The simplest setup. It is also the setup that MS more or less recommends from the RDG documentation.
Con : Exposes the server directly to the Internet and makes it highly vulnerable. Also, while I'm not so pessimistic, I know some network security officers who are absolutely paranoid about directly exposing any MS OS to the Internet. You'll also need additional software, such as firewalls and ipsec policy running to truly secure it (unless this is already all done via a firewall in your dmz).
2) Pro : Setting up and testing is quite easy since they're both on the same network.
Cons : It will prolly require extensive testing to ensure that legit programs are not being blocked.
Big CON to both : The biggest con I can see to both though is that they only protect your network from direct attack. It will stop the RDG from being hacked, but neither solution does anything about the client. So in both models, if the client gets hacked, they can potentially see and/or take control of the app you are hosting.
Solution : use something similar to Cisco Secure Desktop. It establishes a VPN connection that doesn't require a client to be installed, and you can control access much more aggressively. Furthermore it will generally completely drop the connection if it detects a "hiccup". This could be a legit client hiccup caused literally by something as uncontrollable as the client's DSL line suddenly vibrating due to too strong winds, or it could be an actual hack attempt.
I don't know if this would be feasible for you though.
If not, I would go with Option 2.- Marked As Answer byMatthew Theobald Friday, November 06, 2009 10:02 AM
- Hello Matthew,
Is the suggetsions from J2 answering your questions? Please let me know if you need any further ideas.
Thanks.
· Lionel Chen
TechNet Subscriber Support in forum
If you have any feedback on our support, please contact tngfd@microsoft.com
- Edited byLionel Chen - MSFTMSFT, ModeratorWednesday, November 04, 2009 8:08 AMtypo
I am satisfied with J2's answers w.r.t. the two network topologies that I proposed. Are there any other network topologies that I should be considering?
Thanks,
MatthewHello Matthew,
Thanks for your feedback.
If you want a simple topology with one RD Gateway and one Session Host/RemoteApp, there is no more topology options. Generally, as J2 mentioned, we set up the RD Gateway inside the network and protected by the firewall, because RD Gateway contains some credential information and policy settings (RAP and CAP), exposing the server in DMZ environment could cause security risks. Instead, if you use RD Web Access to publish the RemoteApp programs, the Web server can be located in the DMZ because no critical information is stored.
If you want to improve the topology by enhancing availability, you could consider to setup a RD Connection Broker role to supply load balancing and reconnection features.
For related information, please refer to:
Deploying Remote Desktop Web Access with Remote Desktop Connection Broker Step-by-Step Guide
http://technet.microsoft.com/en-us/library/dd883258(WS.10).aspx
and
Deploying RemoteApp Programs to the Start Menu by Using RemoteApp and Desktop Connection Step-by-Step Guide
http://technet.microsoft.com/en-us/library/dd772639(WS.10).aspx
Hope the information helps. Thanks for your cooperation and patience, Matthew.
· Lionel Chen
TechNet Subscriber Support in forum
If you have any feedback on our support, please contact tngfd@microsoft.com
- Marked As Answer byMatthew Theobald Friday, November 06, 2009 10:03 AM
