My last post on TSWeb (aka TSAC or Remote Desktop Web Connection) continues to be one of my most-hit blogs, so I spent a little time working with the TSWeb default connection page to try to simplify some of the bits that people were asking about. The aforementioned post describes how it works - this is more focused on the "getting it set up" part.
So, here's a quick how-to guide on publishing multiple internal RDP servers using ISA 2004, a single external IP Address and a mildly edited TSWeb connection page that allows you to specify the connection port number as well.
You Will Need:
ISA 2004 installed as an edge firewall (Server Publishing of internal IPs must be available)
NB if your router/firewall/edge device can do Port Address Translation, it'll work just as well, but the specific steps here are for ISA. If you have additional external firewalls, further configuration will be required.
A Web Server with the TSWeb package installed on it (an internal desktop may also be fine for this).
The hacked-up connection page (sorry about the formatting, it's just an example!) in the TSWeb directory (by default, c:\Inetpub\TSWeb, I think).
Before We Start Fiddling
Check that the regular TSWeb works correctly within your network.
Web Publish the TSWeb directory
If you're not web publishing and are more an "MSTSC" kind of person, then skip this step. Otherwise, if you want to actually use the Web connection software, you need to publish the TSWeb files.
Set up a Web Publishing rule that exposes the /tsweb/* folder from the internal Web Server to the External network. (It's good to keep it locked down to just that folder and contents if that's all you're publishing).
Test the Web Publishing rule - from the Internet, you should be able to connect to and display the connection page, but actually connecting to any internal computers should not be possible (yet). If you can't get to the www.example.com/tsweb page at this point, troubleshoot that first.
ISA 2004 allows you to adjust port assignments while publishing, and that's what these steps show you how to accomplish: we're going to map the external IP address of the server to the internal IP address of the client, using slightly different ports: for eg, www.example.com:3390 will map to 10.0.0.15:3389 (the default TS port, so no changes are required on the client). The next one might be 3391, 3392 and so on - it's basically arbitrary, and up to you.
If you have another firewall that can do Port Address Translation, these steps won't apply directly, but the theory's the same.
1. Right-click Firewall Policy, create a new Server Publishing rule. Call it something descriptive, like "RDP to Barry's PC", or "TS01 ext port 3390".
2. Type the IP address of the machine on the internal network, hit Next.
3. Pick the RDP Server protocol, then click the Ports... button.
4. This is where the magic happens - unlike ISA 2000, you can modify either end of the connection to point at a non-standard port. In this case, we're just incrementing the default RDP port 3389 by one, to 3390. Firewall ports are the "listening" port for incoming traffic, Published Server ports are the ports for the internal server.
5. When you've set the above, choose the External network to listen on (it will only work for connections to the External NIC)
6. When you're done, the rule should look something like this (before clicking Apply - don't forget to click Apply before trying it!)
Once the internal machine is Server Published, test it with the standalone RDP client from an external client (Start, Run, MSTSC) (we're not testing the Web version yet). On RDP clients version 5.1 (XP) and above, it should now work when you type www.example.com:3390 into the connection dialog box. Note that the Web version does not support this syntax by default, so the out-of-box Web version won't work yet. That's what the example page below lets you do!
If you're having a problem connecting using MSTSC externally, you need to troubleshoot and fix that problem now. Assuming everything else works, one vaguely-likely possibility is that the internal server is not a SecureNAT client (that is, it doesn't route unknown IP addresses back through the ISA Server using its Default Gateway).
If you're in this situation but happy with your internal routing, and don't want to reconfigure it for the published server, you can modify the rule properties so that requests appear to come from the ISA Server computer, rather than from the Internet (the default for a Server Publishing rule - cool thing, in 2004 this is a per-rule setting, not a global setting as in ISA 2000).
Alternatively, look at the ISA Server Monitoring snap-in, Logging section to work out whether a rule is preventing access.
I hacked up the TSWeb-supplied default.htm file to produce an external.htm file (actually, two files with the same name in different zip files, in the same zip file. Got it? You just use the one you like better).
The basic difference is that the modified versions can handle a servername and port, instead of just a server name. The ServerList page demonstrates a selectable list of servers:
while the ServerTyped version lets the user manually type the name and port of the server using the servername:port format:
They're both fundamentally the same file that fiddle in the same way with the AdvancedSettings2.RdpPort property to work their magic - just with comments in different places - and they're just an example, all care taken, but no responsibility accepted. There Might Be Bugs*. Download them both here.
So, open the package that you want to use, then put the external.htm file in the TSWeb directory on the web server. It won't affect any of the existing files in that folder.
If you're using the selection list of servers file, you'll need to find the EDITEDIT bit of the HTML, and replace the example domain names and ports with your own real domain name (or external IP address, but domains are easier to use and less hassle in case of IP address changes) and port, then save the file.
Then, try browsing to http://www.example.com/tsweb/external.htm , and try it out - it should all work.
[Update 17 Aug 2004] And wouldn't you know it - Tom's had this out for a while, though focused on the port mechanics rather than the Web bits. And I thought I was being so novel!