Publishing Remote Desktop Web Connection Sites with the ISA Firewall Part 1 – Remote Desktop Web Services Concepts

Publishing Remote Desktop Web Connection Sites with the ISA Firewall
Part 1 – Remote Desktop Web Services Concepts
By Thomas W Shinder MD, MVP

The Windows XP and Windows Server 2003 Remote Desktop Web Connection feature allows you to connect to RDP servers through an easy to use Web browser interface. This article is dedicated to discussing how the Remote Desktop Web Connection Actually works and how it does NOT work, and also, DNS Issues with Remote Desktop Web connections

The Windows XP and Windows Server 2003 Remote Desktop Web Connection feature allows you to connect to RDP servers through an easy to use Web browser interface. The Remote Desktop Web Connection feature provides:

• An easy way to deploy the RDP client software without requiring users to provision their dedicated Remote Desktop Client application. Users connect to a Web site and then download an ActiveX control that enables the remote desktop interface to appear in the browser window
• A Quick and dirty way to provide remote access via the RDP protocol to connect to user desktops and RDP servers
• A simplified approach to deploying RDP clients across multiple Windows platforms. You don’t need to worry about the version of RDP software installed on the client, or if the RDP client software is even installed on the client operating system.
• An alternative to VPN connectivity for vendors who need access to DMZ resources. You don’t need to help vendors configure their VPN client application or even create a CMAK profile. All they need to do is connect to the Remote Desktop Web Connection Site and enter the correct server name and user credentials.

It should be clear that the main reason for using the remote desktop Web connection feature is to simplify provisioning of RDP clients.

The remainder of this article is dedicated to discussing the following topics:

• How the Remote Desktop Web Connection Actually works and how it does NOT work
• DNS Issues with Remote Desktop Web connections

How the Remote Desktop Web Connection Actually Works and How it does NOT Work

Figure 1 below shows what a lot of people think is going on with the Remote Web Connection process. The following description is WRONG. When reading this description, keep in mind that it is wrong and that I’m providing it to highlight the incorrect thinking of many network administrators.

This figure shows the remote desktop Web connection client making an HTTP (which could be encrypted with SSL) connection to the ISA firewall’s external interface. The ISA firewall then performs stateful application layer inspection on the connection and then reverse proxies the connection request to the Remote Desktop Web Services server. The connection continues to be an RDP connection tunneled in an HTTP header until it reached the Remote Desktop Web Service Server.

At this point, “something happens” that detunnels the encapsulated RDP protocol. Once decapsulated, the exposed RDP communications are forwarded to the terminal server. I suppose then what happens is that the communications from the terminal server are returned to the Remote Desktop Web Services Server, which re-encapsulates the RDP communications with the HTTP header, and then forwards them to the remote desktop Web service client on the Internet.

This would be pretty cool, as the Remote Desktop Web Services Server in this scenario would act as an RDP/HTTP proxy. Unfortunately, things don’t work this way. Again, it does not work this way. Note the WRONG label in figure 1.

Figure 1: How Remote Desktop Web Services doesn’t work

Figure 2 shows what actually happens with the Remote Desktop Web Connection process. The remote desktop Web connection client on the Internet establishes an HTTP connection (which can be secured with SSL) to the Web listener on the external interface of the ISA firewall. The ISA firewall then performs stateful application layer inspection on the connection, and then reverse proxies the connection to the Remote Desktop Web Services Server on the corporate network.

At this point, the Web server returns to the remote client the option to install the RDP ActiveX control. After the ActiveX control is installed, the user can then enter the RDP server name and domain. He can optionally enter a user name and domain name that will be forwarded to the RDP server’s log on page.

After the user enters this information, a second connection is established from the remote desktop Web client to the ISA firewall. This is not an HTTP connection – it is an RDP connection. Unlike the first connection that was made to the Remote Desktop Web Service Server on TCP port 80 (or TCP 443 if SSL encryption is used for the HTTP connection), the second connection is made to the default RDP protocol port, which is TCP port 3389. The ISA firewall’s RDP Server Publishing Rule listener intercepts the second connection and the connection attempt is forwarded to the RDP server the user wants to connect to.

Figure 2

At no point is the RDP connection made within an HTTP tunnel. This means if the remote desktop Web client on the Internet is behind a NAT device or firewall that does not allow outbound TCP port 3389, then the RDP connection to the terminal server will fail. It does not matter if outbound HTTP was allowed. The only thing you get when outbound HTTP is allowed from the network on which the remote desktop Web service client is located is a connection to the Remote Desktop Web Service Server and the log on Web page.

You won’t be able to connect after entering the required information on the Web page because outbound RDP is required (actually, outbound TCP port 3389 is required, the protocol itself isn’t required unless the firewall performs stateful application layer inspection on the RDP protocol itself).

DNS Issues with Remote Desktop Web Connections

Now that we have that out of the way, let’s discuss DNS issues related to connecting using the Remote Desktop Web client. The DNS issues tie into a major misconception regarding how the remote desktop Web client connects to the RDP server on the corporate network.

Figure 3 shows how connections to the RDP server do not work. Again, I am going over the details of how it does not work because it seems like many network administrators believe it does work in the way I’m describing here. Read the following while keeping in mind that the following description is false and does not describe how the connection process works.

In this fantasy scenario, the user enters the name of the RDP server located on the internal network into the server text box on the remote desktop Web access page. In this example, let’s suppose that the user enters SERVER1 into the text box.

The connection request is sent to the ISA firewall’s Web listener, which statefully inspects the incoming communications. The ISA firewall then performs reverse proxy and forwards the connection to the Remote Desktop Web Services Server. Then the Remote Desktop Web Services Server queries an internal DNS server to resolve the name SERVER1 to its internal IP address.

After resolving the name, the Remote Desktop Web Services Server forwards the RDP request to the IP address of the terminal server. At this point, the terminal server establishes some sort of session with the remote desktop Web service client on the Internet, at which point the remote desktop Web services client and the terminal server communicate directly with one another.

It would be really cool if things worked that way, but they don’t. Again, the above explanation and the schematic in figure 3 shows how many network administrators think the process works, but it does not work this way.

Figure 3: How connections to the RDP server do not work

Figure 4 shows what actually takes place when the remote desktop Web services client connects to the RDP server on the internal network. Here we see in the black lines the remote desktop Web services client initiating a connection to the Remote Desktop Web Services server. The client then receives the Web page where the user enters the name of the RDP server that he wants to connect to.

In this example, the user enters into remote desktop Web page in the Server text box SERVER1.msfirewall.org. The client then queries a public DNS server to resolve the name of SERVER1.msfirewall.org, which must resolve to the IP address used to access the listener used by the RDP Server Publishing Rule. The remote client then connects to the RDP Server Publishing Rule listener and the connection is forwarded to the RDP server on the corporate network.

Figure 4: How connections to the RDP server actually work

As you can see, the server name the users enter into the Server name text box is NOT the NetBIOS name of the server on the corporate network. It’s not even the FQDN used by the terminal server on the corporate network. The name can be anything you want, as long as that name resolves to an IP address used by the RDP Server Publishing Rule to publish a specific terminal server.

What if you want to publish multiple terminal servers that are accessible via the remote desktop Web services Web page? In this case, you need to create multiple RDP Server Publishing Rules, one rule for each RDP server you want to publish. You will also need to create a public DNS entry for each of these public servers.

For example, look at the setup in Figure 5. In this scenario there are three terminal servers on the corporate network. You want to make it possible for remote users to access these servers via the Remote Desktop Web Services connection. The servers on the internal network are named SERVER1, SERVER2 and SERVER3. In order for this to work, you will need to:

• Create a Web Publishing Rule to publish the Remote Desktop Web Services server
• Create three RDP Server Publishing Rules, one for each RDP server. This requires that you have at least three IP addresses bound to the external interface of the ISA firewall
• Configure the public DNS server with Host (A) records that resolve the names of the Web server and RDP servers to the correct IP addresses on the external interface of the ISA firewall, matching the IP addresses used for each rule’s listener

Figure 5: Publishing multiple RDP servers

Note:
This discussion focuses on default settings on the Remote Desktop Web Server, the remote desktop Web client, and the RDP protocol definitions and listener settings on the ISA firewall. It is possible to manipulate the configuration on each of these devices so that you can use a single IP address on the external interface of the ISA firewall to publish these services by manipulating the RDP listener port on each terminal server, changing the Protocol Definition used in the Server Publishing Rule, and the reconfiguring the .asp page on the Remote Desktop Web Services server. Send me a note at [email protected] if you’re interested in such an article. If there is enough interest to make it worth the time, I’ll do another article on how to perform this type of advanced configuration.

Have Questions about the article?  Ask at: http://tinyurl.com/7slz9

Summary

In this article we discussed a number of issues related to providing remote access to the remote desktop Web site. The main focus was to correct some common misconceptions regarding how the remote desktop Web service works and provide detailed explanations of how the technology does work. I also discussed several networking issues regarding Web and Server Publishing Rules that you need to be aware of before deploying a working remote desktop Web site solution using ISA firewalls. In part two of this article we’ll go over the step by step procedures for publishing the remote desktop Web services Web site and the required RDP Server Publishing Rule.

If you would like to read the other articles in the series please go to: 

• Publishing Remote Desktop Web Connection Sites with the ISA Firewall Part 2: Creating the Web and Server Publishing Rules
• Publishing Remote Desktop Web Connection Sites with the ISA Firewall Part 3: Testing and Troubleshooting