Chapter 27: Advanced Server Publishing with ISA Server

Introduction

ISA Server allows you to control what internal network clients can access on the Internet and what external, Internet-based clients can access on the internal network. You are "publishing" servers when you configure the ISA server to allow external network clients access to resources on the internal network. ISA Server supports two types of publishing:

• Web publishing

• Server publishing

Web publishing rules publish HTTP and FTP servers located on the internal network, and give you the ability to do the following:

• Publish multiple Web servers using a single IP address on the external interface of the ISA server.

• Use an Incoming Web Requests listener to accept inbound HTTP requests.

• Authenticate with the ISA server at the Incoming Web Requests listener using basic, integrated, digest, or certificate authentication.

• Perform port redirection. Only the Web Proxy service can accept requests on a specific port on the external interface of the ISA server and forward it to an alternate port on an internal server.

• Examine the HTTP header and make decisions on how to redirect the request based on the destination URL.

• Bridge Secure Sockets Layer (SSL) requests as HTTP requests. This reduces processing overhead on the internal Web server and allows the ISA server to handle the SSL processing.

• Bridge SSL requests as SSL requests. This allows the ISA server to terminate an SSL connection on its external interface and then create a second SSL connection between its internal interface and the Web server on the internal network

• Extend the security features provided by the Web Proxy service by installing Web filters. Even the URLScan ISAPI filter can be installed on the ISA server to improve security for your Web publishing rules.

To get a better idea of how Web publishing rules work, consider the following scenario:

You have an ISA server with a single public IP address assigned to its external interface. You want to publish three Web servers on the internal network using one external network IP address. You also want to use the same public fully qualified domain name (FQDN) that users will type in to access the three servers on the internal network. The only difference is that the users will use a different path in the URL to access the servers; for example, /catalog, /specs, and /orders.

Note in this example that we used the path to determine what server the incoming request was redirected to. This is a very handy feature, but one limitation is that the request is redirected to the same folder on the server on the internal network. What you cannot do is have an incoming request to http://www.mydomain.com/server1 and redirect that request to http://server1. You can redirect to different servers based on the path, but you cannot redirect to an alternate path. This was something you could do with Proxy Server 2.0, but that functionality is not included with ISA Server.

Another feature of Web publishing rules is that requests handled by Web publishing rules pass the IP address of the internal interface of the ISA server to the internal Web server. The original IP address in the incoming client request is not included. The internal Web server's log files show all requests coming from the internal interface of the ISA server. This might create some problems for you if you want or need to analyze the Web server's log files for traffic patterns. You'll have to extract the information from the ISA server's Web Proxy logs.

Note

The only way you can get the original source IP address in the Web server's log files is to use server publishing rules. There is no way to pass the original source IP address to the internal Web server if you use Web publishing rules. There are a number of log analyzers you can run against the Web Proxy log that can assist you in site analysis. Check them out at www.isaserver.org/software/ISA/Reporting/.

Server publishing rules allow you to publish almost any type of server. However, server publishing rules lack the power and flexibility of Web publishing rules because a server publishing rule is essentially a reverse NAT mapping. Unlike Web publishing rules, server publishing rules do not have a service such as the Web Proxy service to examine application layer headers. Server publishing rules give you the ability to do the following:

• Map an IP address and port number on the external interface of the ISA server to an IP address on the same port number on an internal network server.

• Publish any protocol that has a primary connection as inbound. Server publishing rules use protocol definitions found in the Protocol Definitions node in the ISA Server Management console.

• Use client address sets to control what IP addresses on the external network can access a server publishing rule. For example, you can publish a Terminal Server on the internal network and allow only the IP address of your home computer access to that server publishing rule.

• Use "smart" application-layer filters that examine the application layer data as it moves through the ISA server. These application-layer filters perform a variety of functions to provide better security.

While server publishing rules do not automatically take advantage of application-layer data analysis, they will leverage the features of a number of application filters included with ISA Server. For example, you can publish SMTP, DNS, and POP3 servers on the internal network and have them protected against buffer overflows by enabling the SMTP, DNS, and POP3 application filters, respectively. The SMTP application filter can even go one step further and be used in conjunction with the SMTP message screener to filter out spam. The ISA Server SMTP Message Screener further extends the examination of the application-layer data by reviewing e-mail message content and blocking messages based on rules that you configure.

Server publishing rules can use application filters to help them publish complex protocols. A complex protocol is any protocol requiring one or more secondary connections. Only Firewall clients can use complex protocols. This creates a problem for servers published via server publishing rules because these servers need to be configured as SecureNAT clients. ISA Server comes with the FTP Access application filter, which allows you to publish FTP servers, even though these servers are configured as SecureNAT clients. Since FTP servers require secondary connections, the FTP access application filter manages the connection for the FTP server (which is configured as a SecureNAT client) on the internal network.

Server publishing rules allow you to publish almost any protocol, although you might have to create your own application filter to support servers requiring complex protocols. Another advantage that server publishing rules have over Web publishing rules is that you can record the actual source IP address in the publishing server's logs. The ISA server does not replace the source IP address when passing packets via server publishing rules.

Note

Some people refer to the situation in which the ISA server does not replace the source IP address in the packet as "half NAT." You can configure the ISA server to perform a "full NAT" and replace the source IP address with the IP address of the internal interface of the ISA server. This might be a preferred configuration when you want to avoid changing your network infrastructure just to support publishing servers. When you enable "full NAT," the only route required is one that allows the publishing server access to the network ID on which the internal interface of the ISA server is located. This allows you to avoid configuring a default gateway on the publishing server that routes packets to the Internet. Since the publishing server will not be responding to an Internet address, it will be responding to an internal network address (the address of the internal interface of the ISA server).

How do server publishing rules work? The ISA server's external IP address on TCP port 25 receives an incoming packet. The ISA server checks to see if there is a server publishing rule that matches packets arriving on the ISA server's external interface. If there is, the ISA server forwards the request to the internal network IP address listed in the server publishing rule.

Server publishing rules work well if there is only one server on the internal network that you want to publish for a particular service. For example, we have a single IP address on the external interface of the ISA server and we publish a single SMTP server on the internal network. This works without any problems. However, what if we have two SMTP servers on the internal network and we want to publish them both? You can do this, but not with a single IP address on the external interface of the ISA server. Unlike the situation with the Web Proxy service and its Web publishing rules, you cannot publish the same service multiple times using a single IP address on the external interface of the ISA server.

Publishing the same service multiple times with a single IP address on the external interface creates port contention. The ISA server realizes this and does not let you create two rules publishing the same service on the same external IP address. While the ISA server knows that you're trying to use the same socket twice on the external interface when you try to create two server publishing rules, you can still have problems with port contention if you run other services on the ISA server that listen on the same port as the service you want to publish.

Port contention created by non-ISA services on the ISA server is a common problem. This might happen if you are running any of the Internet Information Server (IIS) services on the ISA Server machine and then try to publish the same service located on an internal network server. You'll encounter the same problem if you try to publish Terminal Services and the Terminal server is running on the ISA server, or if you have Exchange 2000 installed on the ISA server and try to publish IMAP or POP3 services on the internal network (or even when those services are located on the ISA server itself).

Because port contention is a common problem for both Web and server publishing rules, let's look at how to handle the most common reason for this problem: IIS socket pooling. After you learn how to disable socket pooling, we'll get down to the details of publishing various services on the internal network using Web and server publishing rules.