Red Line Software - we help you manage the efficiency of your office operations.

One of the most common pieces of advice I give regarding ISA firewall access rules and firewall policy is "setup a split DNS and configure those sites for Direct Access". In the first part of a two-part series on Direct Access, I'll discuss what Direct Access is and how to Configure Direct Access for Web Proxy clients.

One of the best things I can hear from a new ISA firewall administrator whoÒs having problems accessing a Web site from behind an ISA firewall is "it worked when we were using a PIX". You have to ask yourself why they site worked when using a PIX. Was the PIX providing real security? Is "easy access" to all sites using all protocols your definition of security? If the ISA firewall blocks access to sites that you were previously able to reach without thinking about firewall configuration, then you need to take a long, hard look at the security and outbound access control your previous security solution provided.

However, there will be times when you have problems accessing some sites from behind the ISA firewall. Not all Web site programmers or administrators are fully aware that many organizations use sophisticated, blended stateful packet inspection and proxy firewalls (like the ISA firewall) to protect their corporate assets. Because of this, connecting to their Web sites can be problematic. YouÒll often find that these sites are Java based, but Java isnÒt the only technology that falls victim to poor coding and implementation practices. For example, another common problem is seen with sites and applications that do not work correctly with authenticating Web proxies.

When you run into this type of problematic site, the solution is to configure that site for Direct Access. Direct Access works a bit differently depending on the ISA client type youÒre using:

• For Web Proxy client connections, Direct Access enables the client to use an alternate method to connect to the resource that bypasses the Web Proxy client configuration. The client system can use either its SecureNAT or Firewall client configuration to access the resource, with the Firewall client option being more secure
• For Firewall clients, Direct Access enables the host to bypass the Firewall client configuration to connect directly to a host that is on the same ISA firewall Network as the client making the request

WeÒll cover both types of Direct Access Configuration in this two part article. In part one (this article) weÒll discuss Direct Access configuration for Web Proxy clients.

Direct Access for Web Proxy Clients

YouÒll likely find there are a few sites your clients canÒt access when connecting to the site via the ISA firewallÒs Web Proxy filter. By default, the ISA firewallÒs HTTP Protocol Definition binds the HTTP Web Proxy filter to the HTTP protocol. This allows the ISA firewall to pass all Web (HTTP, HTTPS and HTTP-tunneled FTP) connections to the Web Proxy filter on the ISA firewall and benefit from the ISA firewallÒs Web caching and deep HTTP application layer inspection feature set.

While this is a good thing, you sometimes need to bypass the Web Proxy component to access sites that donÒt work correctly with firewallÒs Web Proxy filter. LetÒs look at an example of how Direct Access can solve a connectivity issue with a site that does work correctly with a Web proxy firewall.

Fist, weÒll assume that youÒre running a high security environment and have installed the Firewall client on all client operating systems, and that youÒve configured all clients as Web Proxy clients (which can be done automatically during Firewall client installation). The problem is that you want to want to use Outlook Express to connect to your Hotmail account. YouÒve created a simple firewall policy on the ISA firewall that includes the following rule set:

1. Allow DNS outbound for all users
2. Allow all protocols outbound access to all sites for authenticated users
3. The default rule, what blocks all traffic moving through the ISA firewall

This rule set looks like that in the figure below.

Now weÒll configure the Firewall and Web Proxy client on the default Internal Network to connect to the Hotmail site using Outlook Express. When you try to access the site youÒll see the following error in the Outlook Express client.

The error message includes the key phrase Proxy Authentication Required (The ISA Server requires authorization to full the request. Access to the Web Proxy service is denied). This demonstrates that the Outlook Express application does not work correctly with authenticating Web Proxy firewalls. The solution is to bypass the Web Proxy using Direct Access and enable the client system to leverage its Firewall client configuration to access the Hotmail Site.

Note that this solution allows you to require authentication with the ISA firewall before access is allowed. The Firewall client enforces our high security requirements by sending credentials to the ISA firewall, even when the Web Proxy client configuration isnÒt being used due to Direct Access. We do not want to remove our authentication requirements for outbound access, and we donÒt need to. We just use the Firewall client configuration to access the site and our strong outbound access control firewall policy is enforced.

We configure Direct Access in the Properties of the ISA firewall Network from which the request is received by the ISA firewall. For example, if you have four network interfaces installed on the ISA firewall that connect to the default External Network, the default Internal Network, a DMZ Network and a Services Network, and the client making the outbound request is located on the default Internal Network, then you need to configure the Direct Access settings in the Properties of the default Internal Network.

To reach the Properties of the Network, open the Microsoft Internet Security and Acceleration Server 2004 management console and then expand the server name. Expand the Configuration node and click the Networks node. In the details pane, click the Networks tab and then double click the Internal Network.

In the Internal Properties dialog box, click the Web Browser tab. On the Web Browser tab, click the Add button.

In the Add Server dialog box, select the Domain or computer option and enter the name of the site that you want Direct Access to be used. In this example, one of the sites that we require Direct Access is the hotmail.com domain. Enter *.hotmail.com in the text box (the wildcard at the beginning of the URL will allow Direct Access to all servers in the Hotmail domain). Click OK.

Repeat the process to add the following domains:

*.msn.com
*.passport.com
*.passport.net

Click Apply and then click OK in the Internal Properties dialog box. Click Apply to save the changes and update the firewall policy. Click OK in the Apply New Configuration dialog box.

The new configuration information for the Firewall and Web Proxy clients is stored on the ISA firewall. By default, the Firewall and Web Proxy clients automatically update their configuration every six hours. You can force the clients to update their configuration immediately by restarting the client computer, or you can use the Firewall client application to force the update. This is one of the many reasons why you never want to hide the Firewall client icon in the system tray.

Double click on the Firewall client icon in the system tray Click the Test Server button. This forces the Firewall client to pull the new configuration information from the ISA firewall. Click Close in the Testing ISA Server dialog box when the test completes, then click the Apply button in the Microsoft Firewall Client for ISA Server 2004 dialog box.

Click the Web Browser tab. Confirm that there is a checkmark in the Enable Web browser automatic configuration checkbox and click Configure Now, and then click OK in the Web Browser Settings Update dialog box. Note that this autoconfiguration setting is not the same as the autoconfiguration setting in the browserÒs Properties dialog box. The autoconfiguration settings in the browserÒs Properties dialog box apply to wpad entries that enable the browser to automatically find the ISA firewall.

Click Apply and then click OK in the Microsoft Firewall Client for ISA Server 2004 dialog box.

YouÒll now be able to connect when you open Outlook Express and access your e-mail from the Hotmail site. In the ISA firewallÒs log file you can see that the connections are authenticated. You know that itÒs the Firewall client making the connection instead of the Web proxy client because the URL shows the IP address of the Hotmail site and not the FQDN. You only see the FQDN in the log file when the Web Proxy client makes the connection. You can use third party utilities to get the URLs from the Firewall client connections.

The great thing about Direct Access when the clients are configured as both Web Proxy and Firewall clients (which is what you should always do) is that even through we use Direct Access to bypass the Web proxy service on the ISA firewall, we donÒt have to lower our security posture by removing authentication for outbound connections. The Firewall client picks up for the Web Proxy client and does the authentication heavy lifting.

The same principles apply to any site that gives you problems because of incompatibility with the ISA firewallÒs Web Proxy filter. Just enter the siteÒs name or IP address in the list of sites requiring Direct Access, and the Firewall or SecureNAT client configuration will take over.

Note that if you havenÒt deployed the Firewall client (which is the case for servers, which typically should not have the Firewall client installed), then you need to create an anonymous access rule that applies to the IP addresses of the clients on the ISA firewall Protected Network that need to use Direct Access to get to the problematic site.

For example, suppose you have a crazy boss and he wants to run Outlook Express on a domain controller. YouÒve told him itÒs not a good idea to run client applications on servers. But he pays the bills so you have to do what he tells you to do. You donÒt want to install the Firewall client on the domain controller, since a DC is a server. What you can do is add a rule allowing the domain controller anonymous access to the required sites.

This solution requires:

• A Domain Name Set for the sites you need to access
• A Computer Set for the machines that donÒt have the Firewall client installed
• An Access Rule that allows the Computer Set access to the required protocols to the required sites

The Domain Name Set would look like what appears in the figure below. The set includes the same sites that we configured for Web browser Direct Access for the Network from which the request arrives to the ISA firewall.

The Computer Set would include the IP address of servers you want to access the approved site without authenticating to the ISA firewall. For example, for our boss who wants to use Outlook Express from the DC, the Computer Set would look like what appears in the figure below.

The Access Rule allowing outbound access to the Hotmail site for the non-authenticating client would appear like that in the figure below. Note that you need to put this rule above any rule requiring authentication for the same protocols. In general, you should put your anonymous access rules above your authenticated access rules.

Be aware that you will not get user information in the log files when you donÒt require authentication. For this reason, I recommend that you enable anonymous outbound connections only when there are strong technical or political reasons for doing do.

Summary

In this article, part one of a two part series on configuring Direct Access, we discussed how to configure Direct Access for Web Proxy clients. Direct Access for Web Proxy clients enables the Web Proxy client machines to bypass their Web Proxy configuration and leverage their SecureNAT or Firewall client configuration to access problematic sites. In this next article in this series weÒll discuss configuring Direct Access for Firewall clients and why you need to configure Direct Access for Firewall client scenarios.

Author: Thomas Shinder

Dr. Thomas W. Shinder is an MCSE, MCP+I, and MCT. He has worked as a technology trainer and consultant in the Dallas-Ft. Worth metro area, assisting in development and implementation of IP-based communications strategies for major firms such as Xerox, Lucent and FINA.