Fixing Common Web Publishing Problems: Part 2
By Thomas W Shinder M.D.
In the first part of this two part article on fixing common Web publishing problems I focused on Destination Set issues. If you missed that article, check it out at http://www.isaserver.org/tutorials/WebPubProblems.html. In this second part of the two part article, we’ll look at the following issues:
Let’s look at each of these issues in more detail.
—————————————
Redirecting to a Web Root
—————————————
From what I’ve heard, Proxy Server 2.0 was able to redirect to the Web root based on a path statement. I say that this is from what I’ve heard because I haven’t worked with Proxy Server 2.0 enough to be aware of this feature. However, enough people complain about this problem with ISA Server to make it clear that you could do something like this with Proxy Server 2.0!
What I do I mean by redirecting to the Web root based on a path? Suppose you want to want to publish two Web sites on the internal network. You want external users to access one of the sites by using the URL www.website.com/site1 and the other site by using www.website.com/site2. The problem with ISA Server is that if the user if users use a URL with a path in it, that same path must be available on the internal network Web server and the users will be forwarded to that same directory. In this example, users will be redirected to the /site1 directory when they are forwarded to one server, and redirected to the /site2 directory when forwarded to the other servers. No, you can’t fix this problem or make it work like Proxy Server 2.0.
However, there is a workaround. You can configure the redirection at the Web site itself. First, open the Internet Information Services console and expand your server name and then your Web site name. Right click on the folder that you want to redirect to root and click the Properties command.
In this example users on the Internet who type http://www.mydomain.com/dallas should be redirected to the root directory of the Web server and to a page in the root named dallas.htm. Note that the /dallas in the URL is a directory, and not a file name. Users are directed to a file in the root directory. The Web server sends back to the Web browser the new URL and the browser issues a request for the new URL.
Note that a Web Publishing Rule is required to allow the redirection to the Web root. The question is whether you want to just add www.mydomain.com to the Destination Set you’re already using the Web Publishing Rule that includes the path, or if you want to create a second Web Publishing Rule. Primary reasons for creating a new Web Publishing Rule is that you want to use authentication, or another authentication method, for the Web root access. If you don’t have any different requirements, you can just add to the existing Destination Set.
The new Destination Set entry might include the FQDN for the Web site and the path statement. The path statement allows you to limit access to the Web root. If you did not include the path statement, users would be redirected to the default document in the Web root. However, the path statement is unnecessary if you don’t mind users being redirected to the default document in the Web root and you don’t mind them access objects anywhere in the Web site hierarchy. That is to say, you will have to use other methods of access control if you redirect them to the Web Root and don’t use a path in the Destination Set entry.
For example, you have created a Destination Set for www.domain.com with a path of /dallas and you’re using that Destination Set in a Web Publishing Rule. You want users who type http://www.domain.com/dallas to be redirected to the root of a server called SERVER1 on your internal network. You don’t need the Destination Set configuration for access control, so you just add an entry to the Destination Set you’re already using to allow the users to the /dallas subdiretory. When users attempt to access http://www.domain.com/dallas, the Web server tells them to go to http://www.domain.com. Since you’ve added
www.domain.com to the Destination Set, the external users are sent to the Web root.
Now, things get sticky because the whole reason why you’re using paths is because you want to use the same FQDNs to redirect to different servers on the internal network. Unfortunately, that won’t work. For example, suppose you want to redirect to another server using the Destination Set www.domain.com/houston. The FQDN is the same, but the path is different. The problem is that you’ve already created a Destination Set that contains www.domain.com and its being used by the first rule you created and so requests will be sent to SERVER1 on the internal network, when you actually wanted it to go to SERVER2.
The solution is to use a different FQDN, like www2.domain.com. You use this second FQDN at the Web site and in the second Web Publishing Rule. Now when the external user tries to access www.domain.com/houston, the Web server informs the browser to access www1.domain.com. You will need your Web Publishing Rule to use a Destination Set that contains the entry www1.domain.com and that forwards to SERVER2.
Keep your eyes peeled for a tutorial in the near future with the step by steps of how to redirect to the Web root based on path statements.
—————————————
Port and Protocol Redirection
—————————————
You can use Web Publishing Rules to publish FTP sites on your internal network. The difference between using a Web Publishing Rule and a Server Publishing Rule is that people can access the FTP site via HTTP with the Web Publishing Rule. This is a very handy tool for organizations who wish to allow anonymous (and even authenticated) users access to corporate FTP sites. One limitation of using Web Publishing Rules to publish FTP sites is that you can only download from FTP sites published with Web Publishing Rules. However, this should not pose a major problem as no secure corporate site would allow FTP uploads from the Internet.
You’ve probably noticed that there is no option to redirect HTTP requests as FTP requests when you run the Web Publishing Wizard. This creates a bit of confusion for those of you who want to publish FTP sites via a Web Publishing Rule because you expect to see the option while still in the Wizard.
Don’t worry! Its easy to create the HTTP to FTP protocol redirection. First, create the Web Publishing Rule. After you create the Web Publishing Rule, double click on the rule. Click the Bridging tab. Select the option to Redirect HTTP requests as FTP requests. Now when this rule is activated, the request will be forwarded to the internal Web server using the FTP port you configured in the Web Publishing Rule.
For some reason, many ISA Server admins want to publish FTP sites on the internal network that use alternate port numbers. You can use Server Publishing Rules to publish these FTP servers, but you’ll run into problems when you publish FTP sites on an alternate port numbers because the FTP Access Application Filter only supports publishing SecureNAT FTP servers on TCP port 21. You can get around this problem by publishing the FTP site using a Web Publishing rule.
ISA Server Alert
It doesn’t make sense to configure FTP sites to use different ports, since you can bind multiple IP addresses to the Server and use different IP addresses for each internal network FTP server. Private IP addresses are reasonable priced at this time of year J
Click the Action tab in the rule’s Properties dialog box. Type the alternate port number that the internal FTP server listens on in the Connect to this port when bridging request as FTP text box. Click OK and you’re set. Its that easy and you don’t have to mess with the Firewall client on the FTP server and you don’t have to create and configure a wspcfg.ini file.
—————————————
DNS Infrastructure
—————————————
One of the most common errors ISA admins run into when reviewing the Event Log on their ISA Server machines is the dreaded 14120 error. Event ID 14120 comes up when the ISA Server cannot create a packet filter to support a request; the error suggests there is a conflict in the LAT causing the problem. In the overwhelming majority of cases, there is no problem with the LAT. The problem is with name resolution. What is even more confusing about this error is that there doesn’t seem to be anything wrong with name resolution and all the publishing rules are working correctly!
The dreaded 14120 error occurs when internal network client attempt to access a published Web server by “looping back” through the external interface of the ISA Server. The packet filter driver tries to create a packet filter to allow outbound access to the client that made the request; the packet filter driver fails to create the packet filter because the source address of the client making the request is not reachable through the external interface of the ISA Server. This doesn’t cause a problem because the Web Proxy service can still return the response to the internal network client via the internal interface, but it makes the ISA Server packet filter driver very confused and generates the 14120 error.
ISA Server Alert
Remember ISA Server Law #1: Do not loop back through the external interface of the ISA Server to access internal network resources. Internal network clients must access internal network resources directly.
There are three ways to deal with this situation:
- Ignore the error.
- Disable the Alert for Resource Allocation Errors. You can disable the alert in the Alerts node in the ISA Management console.
- Fix your DNS infrastructure
The first two options should be used while you’re waiting to get your DNS infrastructure fixed. You need to fix your DNS infrastructure anyway, so why not use the 14120 error as an excuse to take care of it now. What you need to do is create a DNS zone that is used by the internal network hosts so that internal network clients do not need to loop back through the external interface of the ISA Server.
For example, external network clients access your published Web site via the IP address on the external interface of the ISA Server. You create a DNS zone for your domain that is used by external network clients on a DNS server that is used only by external network clients. You create a second zone for the same domain on another DNS server on the internal network, which is used only by internal network clients. The internal DNS server contains the private IP address of the Web server; this prevents internal network clients from looping back through the external interface of the ISA Server. The internal network clients can access the published Web server directly. Of course, this means creating a split DNS infrastructure. Check out http://www.isaserver.org/tutorials/You_Need_to_Create_a_Split_DNS.html for details on how to create the split DNS.
—————————————
Summary
—————————————
ISA Server Web Publishing Rules make is easy for you to make Web and FTP servers on your internal network. However, there are a few problematic issues that create the most common reasons for Web Publishing Rule failure or unexpected behavior. In this two part article on Web Publishing Rules we covered these common issues and came up with solutions and workarounds for these problems.
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=001323 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom
