Microsoft Internet Security and Acceleration (ISA) Server Publishing FAQ

Article
01/05/2009

This frequently asked questions (FAQ) document provides answers to questions commonly asked about publishing Web sites and internal resources through Microsoft® Internet Security and Acceleration (ISA) Server.

Q. How do I provide authentication on my published Web sites?

A.	ISA Server only supports Basic and Anonymous access at the IIS WWW services itself. If you want to enable other authentication modes, you need to configure those for the ISA Server Web Listener. By default after ISA Server installation, Integrated and Anonymous authentication methods are enabled.

Q. How can I listen for an incoming HTTP request on a custom port on an external interface?

You can change the port configured for the incoming Web listener. In ISA Management, right-click the name of the ISA Server computer or array, and then click Properties. On the Incoming Web Requests tab, in TCP Port, specify the port you want the Web listener to use for incoming HTTP requests.

Q. I have a Web publishing rule that allows incoming requests to an internal Web server. How can I ensure that the actual IP address of the incoming request is logged and not the private IP address of the ISA Server computer?

To get the original requesting IP address, use server publishing rules instead of Web publishing rules. Using server publishing, you can log the requesting host’s original IP address. In Web publishing, the source IP address in the host header is changed to the IP address of the ISA Server internal interface, when a request is forwarded to the published server by the Web Proxy service. Thus, you cannot log the requesting host’s IP address.

Q. Why can’t I do an FTP upload from an internal client computer?

For internal clients that need to do an FTP upload to external sites, the client computer must be configured as a SecureNAT client or Firewall client; because Web Proxy clients cannot do FTP uploads. For these clients, you should enable the FTP Access Filter, and create an allow protocol rule for the predefined FTP protocols you want to allow. Note that you configure a SecureNAT client by setting the client computer’s default gateway to the internal IP address of the ISA Server computer.

Q. When must I use packet filters rather than policy rules?

There are certain configurations that require the use of packet filters. You must use packet filters if:

You publish servers that are located in a perimeter network (DMZ), and you want to make them accessible to external clients.
You run applications or other services on the ISA Server computer itself that need to listen to the Internet.
You want to allow access to protocols that are not based on TCP or UDP. You can create protocol definitions for use in policy rules only for the TCP and UDP protocols. For access to other protocols, you need to create an allow packet filter to open the ports required by the protocol.

Q. In what order does ISA Server prioritize incoming request rules?

When ISA Server processes a request from an external client, it checks IP packet filters, publishing rules, and routing rules to determine if the request is allowed and which internal server should service the request. For an incoming Web request, rules are processed in the following order:

IP packet filters
Web publishing rules
Routing rules

Q. How can I set up a terminal server connection through ISA Server to an internal computer?

A.	For instructions, see Microsoft Knowledge Base article 294720.

Q. What is the difference between SSL tunneling and SSL bridging?

Secure Sockets Layer (SSL) bridging refers to the ability of ISA Server to encrypt or decrypt client HTTPS requests and pass these requests on to a destination Web server.

SSL tunneling allows ISA Server clients to establish a tunnel through the ISA Server computer directly to the Web server with the requested HTTPS object. No SSL processing occurs on the ISA Server computer.

Q. When is SSL tunneling used?

SSL tunneling is used when an internal client browser requests an object using HTTPS on port 8080 through the ISA Server computer. The client makes the request, and ISA Server forwards the request to the destination Web server on SSL port 443. ISA Server returns a connection established message to the client, and from that point the client communicates directly with the Web server.

Q. When is SSL bridging used?

By default, when an internal client uses HTTPS to request an object from a server on the Internet, ISA Server uses SSL tunneling to establish the connection. However, for clients that support secure communication directly with the ISA Server computer, you can configure routing rules to enable SSL bridging instead, as follows:

Forward HTTP requests as SSL: When a client requests an HTTP object, ISA Server encrypts the request and forwards it to the Web server. When the Web server returns the encrypted object, ISA Server decrypts the object and sends it to the client.
Forward SSL requests as SSL: When a client requests an SSL object, ISA Server decrypts the request, and then encrypts it again and forwards it to the Web server. When the Web server returns the encrypted object, ISA Server decrypts it and sends it to the client.
Forward SSL requests as HTTP: When a client requests an SSL object, ISA Server decrypts the request and forwards it to the Web server. When the Web server returns the HTTP object, ISA Server encrypts the object and sends it to the client.

Using SSL bridging instead of SSL tunneling for outgoing client requests increases security. The ISA Server computer intercepts the client request and the client does not establish a direct connection with the external Web server.

SSL bridging can also be configured for incoming Web requests. When an external client uses HTTPS to request an object from a Web server located on your internal network, the client connects by default to port 443 on the ISA Server computer. The ISA Server computer must be configured to listen for SSL requests on port 443, and have a server certificate to authenticate itself to the external client. ISA Server then decrypts the client request, terminating the SSL connection. A Web publishing rule can be configured to forward this request to the publishing Web server as HTTP, SSL (HTTPS), or FTP. If the Web publishing rule is configured to forward the request as HTTPS, the ISA Server becomes the SSL client and sends a request to port 443 on the publishing server. The publishing server needs a server certificate to authenticate itself to the ISA Server, and optionally, the ISA Server computer might require a client certificate to authenticate itself to the publishing server.

Q. What is the difference between Web publishing and server publishing?

Web publishing entails a more complicated configuration, but includes enhanced security features that server publishing does not provide. The following applies to Web publishing:

Uses only HTTP, HTTPS, and FTP protocols.
Allows traffic to be inspected and filtered at the application level. Using application-level filtering, you can examine elements such as the host header, when allowing or disallowing SSL requests.
Uses URLScan for ISA Server (ISA Server Feature Pack 1). URLScan can inspect packet contents and protect your Web site from Code Red and Nimda-style attacks.
Limits external access to specific areas within the Web site, by specifying paths in the destination set.
Authenticates external user requests before forwarding them to the publishing server, thus protecting the internal Web server from malformed authentication sessions.
Using SSL bridging, avoids the overhead of encrypting transactions on the published server. ISA Server handles the SSL requests, and can then convert them to HTTP and forward to the published server.
With SSL bridging you can cache all cacheable Web objects. This helps in offloading the content from the SSL server, which is not normally cacheable.

The following applies to server publishing:

Provides stateful inspection, filtering traffic at the Network and Session layers. It provides no application-layer filtering capabilities, and ISA Server does not inspect incoming SSL packets.
Handles additional protocols that Web publishing cannot handle, in additional to HTTP, HTTPS, and FTP.
Uses application-layer inspection for server publishing when an application filter is registered for a specific protocol. You can see registered application filters in the Application Filters node in ISA Management.
Provides an easy way to ensure encrypted data all the way to the internal published server.
Logs the requesting host’s original IP address. In Web publishing, the source IP address in the host header is changed to the IP address of the ISA Server internal interface, when a request is forwarded to the published server by the Web Proxy service. Thus, you cannot log the requesting host’s IP address.

Q. Can I publish a server that does not have a predefined protocol?

ISA Server provides a number of preconfigured protocol definitions that you can use when creating server publishing rules. Application filters might also include protocol definitions, which cannot be modified. In addition, you can create your own protocol definitions. To do this, you need to specify the following information:

Port number: You must specify a port number between 1 and 65535 to use for the initial connection.
Low-level protocol: Specify either TCP or UDP as your transport protocol.
Direction: Specify Inbound for server publishing rules.
Secondary connections: For a complex user-defined protocol, specify port numbers, protocol, and direction for additional connections that will follow the initial connection.

Q. How can I configure server publishing if my published server’s default gateway is not the ISA Server computer?

A.	A server published using server publishing is actually a SecureNAT client. So, the ISA Server computer should be configured as the default gateway on the published server. If this is not the case, see Microsoft Knowledge Base article 311777 for a workaround..

Q. I am Web publishing a site with SSL, and the SSL connection terminates at the ISA Server external interface. Instead of returning an error to a client who accidentally types “HTTP”, I want to redirect them to HTTPS. How can I do this?

Download isa_redirects.zip at ISATools, and use the examples and script contained in the zip file. There are two scripts in the zip file:

Redir-meta-tag.htm uses an HTML META tag redirection.
Redir-jscript.htm uses JScript redirection.

Read the ISA_Redirect text file included in the zip for instructions on how to use the scripts. Note that once this is configured, it will be the response for all SSL-restricted sites.

For related Microsoft Knowledge Base articles, see KB article 821724, and KB 279681.

Top of page