Using Web Publishing Rules to Publish Co-located Web and FTP Servers
By Thomas W Shinder M.D.
I’ve noticed in the last couple of weeks that a few ISA Server administrators have been struggling with using Web Publishing Rules to publish a Web site and an FTP site on the same internal network server. It’s very easy to publish Web and FTP sites using Web Publishing Rules, but you have to get a few basic concepts down before everything works right. In this article I’ll go over key concepts so that no one ever has this kind of problem again!
Let’s look at a common scenario and find the problems. You have an IIS 5.0 server on the internal network and you want to publish a Web site and an FTP site on that internal network server. You’ve configured both the Web site and FTP site to listen on IP address 192.168.1.10. You have no problems connecting to these sites from clients on the internal network.
Now you want to publish the Web site. You don’t want to bother with public DNS entries for your sites, so you create a Destination Set containing the IP address of the Incoming Web Requests listener. In this case, assume the public address used by the Incoming Web Requests listener is 126.96.36.199. You go to an external network client and type http://188.8.131.52 in the browser and successfully connect to your Web site. All is good so far.
Next, you create a second Web Publishing Rule for the FTP site. You use the same Destination Set and you configure the Rule to redirect HTTP requests as FTP requests (figure 1). You go to an external network client and open an FTP application and try to connect to your FTP site. What happens? It doesn’t work!
Figure 1 Redirecting an HTTP request as an FTP request
There are two problems with this scenario. Let’s take a look at the problems and how to fix them.
Problem #1: You used IP addresses in the Destination Set
I know a lot of you don’t like to hear this, but you must use FQDNs in your Destination Sets! You only create problems for yourself when you use IP addresses in Destination Sets. This scenario provides just one example of how using IP addresses in Destination Sets creates problems.
Let’s look at why using an IP address in the Destination Set makes it impossible to publish both the Web and FTP site. When the Incoming Web Requests listener receives the request, the Web Proxy service examines the URL in the request and compares that information with the Destination Sets used in Web Publishing Rules. When the Web Proxy service finds a match, it follows the directions in the matched Web Publishing Rule on how to redirect the request.
What happens when you have two rules using the same Destination Set? You want to use an IP address in the Destination Set. Now when the incoming request comes in with http://184.108.40.206 in the URL, it can match this to the Destination Set used in both the Web and FTP site’s Web Publishing Rules. Which Web Publishing Rule will be used? The one with the higher priority – that is, the one listed higher up on the list of rules. You can see in figure 2 that Web Publishing Rules are listed in order. If there is a conflict, the one higher up on the list is applied preferentially.
Figure 2 Web Publishing Rules are listed in order
How can you fix the problem? You must use FQDNs in your Destination Sets if you want to use a single IP address on the external interface of your ISA Server. This is the only way the Web Proxy service can decide how to redirect the request. You need to create two Destination Sets: one for the FTP site and one for the Web site.
For example, you create one Destination Set and include the FQDN ftp.domain.com in the Destination Set. Then you create a second Destination Set and include the FQDN www.domain.com in it. Then you create two Web Publishing Rules – one rule uses the Destination Set with ftp.domain.com in it, and the second rule uses the Destination Set with www.domain.com in it.
When users need to connect to the Web site, they use www.domain.com to access the Web site. When users need to connect to the FTP site, they use ftp.domain.com to access the FTP site. This makes it easy for the Web Proxy service to determine what Rule to apply. When it sees www.domain.com in the incoming request, it knows to use the Web Publishing Rule that has www.domain.com in it. When the Web Proxy service sees a request for ftp.domain.com, it knows to use the Web Publishing Rule that uses the Destination Set with ftp.domain.com in it.
Now you can see why using IP addresses in Destination Set is so limiting. There are plenty of other reasons why you shouldn’t use IP addresses in Destination Sets you use to publish Web and FTP sites. But this example should be enough to convince you that IP addresses in Destination Sets are a bad deal.
Problem #2: You used FTP to connect to the FTP site
The second problem is easier to fix. You should not use FTP clients or the FTP protocol to connect to FTP sites that are published using Web Publishing Rules. Remember, Web Publishing Rules use the Incoming Web Requests listeners to accept incoming requests. The listener can only listen for HTTP and HTTPS messages. It cannot listen for incoming FTP requests.
The Web Publishing Rules can redirect HTTP requests as FTP requests. When you use a Web browser to connect to your site at http://ftp.domain.com, the request is sent via HTTP. The Incoming Web Requests listeners picks up the request, gives it to the Web Proxy service, and the Web Proxy service checks for a Rule that applies to ftp.domain.com It finds the Rule, and the Rule says to forward the request as an FTP request. The FTP site responds to the ISA Server and the ISA Server forwards the response it receives from the FTP site.
That’s why you have to use a Web browser, and not an FTP application to access your FTP site published via a Web Publishing Rule. Web Publishing Rules only accept HTTP requests. This also explains why you can’t upload to FTP sites published via Web Publishing Rules. You can never upload to FTP sites when you access the sites via the Web Proxy service.
Help for those without FQDNs
I understand many of you are trying ISA Server for testing and you don’t want to commit to FQDNs for the addresses you’re using on the ISA Server. Whatever the reason for not registering a domain name for your external addresses, I have an answer for you: a dynamic DNS service called TZO (www.tzo.com)
TZO makes it very easy to create Destination Sets with meaningful entries with a minimum of effort. You get a domain name that includes the TZO domain when you use the basic TZO service. For example, you can create a domain name like homebase.tzo.com. TZO will create a wildcard DNS entry for your domain, so that all host names will resolve to the IP address on the external interface of your ISA Server.
For example, suppose you want to create three Destination Sets. One has www.homebase.tzo.com, another has ftp.homebase.tzo.com and the last has www2.homebase.tzo.com. You can use each of these Destination Sets to publish servers on your internal network because TZO resolves any host name in your homebase.tzo.com domain to the external IP address of your ISA Server. Is that cool or what?
Best of all, you can use the TZO service for FREE during a 30-day trial period. Now you don’t have an excuse for not using FQDNs! You can always have access to FQDNs for your Destination Sets when you use TZO. And you’ll find that the price is very reasonable if you decide to keep it.
I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=5;t=001253 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom.