I recently wanted to obtain access to my work development lab. I have a subnet off the normal network that routes through a Linksys NAT device. This allows me to configure a DHCP, DNS, and Proxy service for my lab testing and proof of concept efforts. For example, I have a pair of Active Directory Domain Controllers, Web Servers, ISA Proxy Servers, a pair of Federation servers, etc… All of this runs off of my Hyper-V Server, of course.
Normally I would only need to work on this lab when I was at work but every now and again I find myself working from the house and needing to get into the lab servers. Initially I stared out by creating a publishing rule on my Linksys device that listened on 3389 and forwarded the traffic to my Hyper-V server. I could simply RDP to the Hyper-V server and then use the Hyper-V Server Console to manage the virtual servers. I found over time that some servers required a smoother and more life-like interaction. So I started creating additional mappings on the Linksys device for additional RDP ports (ex. 4000, 4001, 4002) which were mapped to separate virtual machines. This worked fine as long as I remembered which server was mapped to which RDP listening port.
There had to be a better way. Something better than trying to remember the different port assignments; better than opening up all those ports to the world and allowing anyone to RDP to the server for the casual brute force password attack. Better than something so complex that I couldn’t really explain it to co-workers that needed to connect into my lab.
It turns out there is a better way. It’s called Microsoft Windows 2008 Terminal Services Gateway. If you haven’t seen this feature of Windows 2008 you are really missing out. TSG acts as a proxy for incoming RDP sessions, providing boundary authentication, encryption of traffic, and policy based configuration for limiting access to computers and/or user groups.
You simply configure the RDP 6.0 client to connect to the internal server name/ip address (ex. 192.168.1.10) and then configure the Advanced Settings to connect to a TS Gateway.
Awesome! I decided to implement this solution and shed the musical ports method of RDP access. While not wanting to repeat the many articles already out there to configure TSG I did want to share my experience and findings. I found the installation wasn’t very difficult but there were a couple of things worth pointing out.
For starters, a certificate is required on the TSG server. This certificate should have the same common name that is used to connect to the server. So if you have an externally addressable name (ex. lab.domain.com) then you need to get a certificate with a common name of CN=lab.domain.com.
If you used a self-signed certificate (which is an option, there is even a slick menu to create one) you need to distribute the public key to your client so they can put it into their trusted root store.
The TSG server will require Windows 2008 running IIS 7.0 since it depends on RDP over HTTPS. If you are already using the Default Web site (you didn’t delete it did you?) you need understand that the installation will add virtual directories to your site.
TSG depends on port 443 listening for traffic. After the TSG installation completed I noticed that the Default Web site was configured to listen on 443. Not a big deal but it seems that now my default site was also answering standard web traffic on 443. I created a small, insignificant page to answer on that port but I could have simply removed all pages.
When connecting with the RDP client the username/password to authenticate to the TSG is the same one that is passed to the destination server. So if you are using different account names then you will have a connection issue.
That’s about all there is to it. The initial configuration may seem daunting because of the new terms and technologies but after you’re done you will look back at how little is required to get it working. And hey, if you run into problems drop me a note and I will do my best to help out.