ISA Server 2000 (ISA Server) is Microsoft’s new entrant into the firewall market. ISA Server provides firewall, Web proxying, and Web caching features. ISA Server follows Microsoft’s Proxy Server 2.0; it’s much more sophisticated than Proxy Server and is intended to compete with other firewall products such as Checkpoint Software’s Firewall-1 and Cisco’s PIX.

Clients on the internal network can interact with the ISA Server in different ways, depending on the features you require. The ISA Server clients include:

  • The SecureNAT client
  • The Firewall client
  • The Web Proxy client

Each of these ISA Server client types interacts with ISA Server services in a different way and provides its own unique advantages and disadvantages. There are also problems specific to each ISA Server client.

In this Daily Drill Down, I’ll explore the functions of the SecureNAT client and explain ways to troubleshoot connectivity problems with this client. After you finish this Daily Drill Down, you will be able to solve the common problems you’ll encounter when working with the SecureNAT client.

Features of the SecureNAT client
ISA Server supports transparent proxying of client requests through the use of the SecureNAT client. The SecureNAT client is a machine on the internal network that is configured with a default gateway that can route Internet-bound requests to the internal interface of the ISA Server.

If the SecureNAT client is on the same network ID as the internal interface of the ISA Server, the machine will use the internal IP address of the ISA Server as its default gateway. If the client is on a network ID remote from the internal interface of the ISA Server, then the default gateway is set to a router that can forward Internet-bound requests to the internal interface of the ISA Server.

The SecureNAT client is the preferred ISA Server client for non-Microsoft operating systems. For example, if you had a Mac or Linux workstation or server on the internal network, you would configure it as a SecureNAT client. This allows access to the entire range of TCP and UDP-based protocols.

The SecureNAT client also makes publishing servers on the internal network much easier. When you publish a server, you make it available to users on an external network, such as the Internet. In Proxy Server 2.0 environments, administrators would have to go through the unwieldy process of manipulating the wspcfg.ini file, which leads to configuration errors.

Common issues you’ll encounter with the ISA Server SecureNAT client include:

  • Name resolution issues
  • Problems with complex protocols
  • Problems accessing Web sites
  • Problems accessing all protocols
  • Autodial failures

While these are common issues, you’ll see that they can be resolved relatively easily.

Name resolution problems
The SecureNAT client cannot use the ISA Server to resolve names on its behalf. This is in contrast to the Firewall and Web Proxy clients, which can offload name resolution onto the ISA Server. Therefore, you need to configure the SecureNAT client with an address of a DNS server. The DNS server can be one on your internal network or you can use a server on the Internet.

Problems with name resolution for SecureNAT clients revolve around whether the SecureNAT client is configured to use:

  • A DNS server on the internal network
  • A DNS server on the Internet

Let’s look at these issues in more detail.

DNS server on the internal network
If the SecureNAT client is configured to use a DNS server on the internal network, that DNS server must to be able to resolve names for Internet hosts. Most Windows 2000 DNS servers can issue iterative queries to Internet DNS servers as long as the cache.dns file on the DNS server includes the names of the Internet Root servers.

A Windows 2000 DNS server can also be configured to use Forwarders, which can resolve Internet host names on behalf of the internal DNS server.

If you have configured the SecureNAT client to use an internal DNS server, check to see whether the DNS server is able to resolve Internet host names. If the internal DNS server cannot resolve Internet host names, and it has not been configured to use a Forwarder, consider the following possibilities:

  • The internal DNS server has been configured as a Windows 2000 Active Directory Domain Controller and DNS was configured using the Active Directory DNS configuration wizard.
  • The internal DNS server does not have access to a Protocol Rule that allows it to send DNS queries through the ISA Server.

Internal DNS server is an Active Directory domain controller
This problem is related to limitations built into the Active Directory DNS wizard. If during setup the wizard cannot contact one of the Internet Root Domain servers, the DNS wizard will configure the machine as a root server and will fail to populate the Root Hints file with the names and IP addresses of the Internet Root servers. This prevents the internal DNS server from sending queries to Internet DNS servers to resolve Internet host names.

There are two ways to solve this problem:

  1. Manually configure the zone prior to promoting a machine to a domain controller. If a root zone appears as a period (.), delete that zone and restart the computer.
  2. Make sure that the machine is able to access the Internet during Active Directory setup so that a root zone is never created.

The first option entails manually configuring the zone prior to running the dcpromo command. Make sure the zone is able to accept dynamic updates and make it a Standard Primary zone. After dcpromo has completed, the computer restarts. If the wizard was not able to contact an Internet Root server, it will create a bogus Root “.” domain zone. Delete that zone and then configure the machine so that it can perform DNS queries to Internet servers.

The second option allows you to avoid the problem in the first place. Make sure before you run dcpromo that the machine is able to perform DNS queries on the Internet. You must create a Protocol Rule that allows outbound UDP Port 53 messages to pass through the ISA Server and allow the machine to use that Protocol Rule.

The internal DNS server is not able to query an external DNS server
When the internal DNS server is not able to query an external DNS server, the most likely reason is that ISA Server has blocked outbound access to the DNS protocol. Access might have been blocked explicitly by a Deny rule, or there might be no Allow rule. In either event, access to the DNS protocol is blocked.

To solve this problem, just configure a Protocol Rule that allows outbound access to outbound UDP Port 53.

Make sure to test your DNS configuration on the DNS server first. Use the nslookup command. Issue an nslookup query by opening a command prompt and typing the command:

Remember to include the trailing period, or else nslookup will treat the request as an unqualified query and append its own domain name to the request.

The Internal DNS server is configured to use a Forwarder
The internal DNS server can be configured to use a Forwarder. The Forwarder will resolve the request for the internal DNS server, thereby offloading the iterative query process away from the internal DNS server. If the machine has problems contacting the Forwarder, make sure there is a Protocol Rule allowing DNS queries. Also check that you’ve entered the IP address for the Forwarder correctly.

The SecureNAT client is configured to use a DNS server on the Internet
If the SecureNAT client is configured to use a DNS server on the Internet, check that the SecureNAT client has access to a Protocol Rule that allows outbound DNS queries. “Fat fingers” can do a lot of damage, so double-check that the IP address of the Internet DNS server is correctly configured on the SecureNAT client.

A special case is an Exchange 2000 Server configured as a SecureNAT client. If you configure the Exchange 2000 server to perform its own queries to resolve mail domains, the name resolution attempts may fail. That will happen in spite of the fact that you have created a Protocol Rule that allows outbound requests to UDP Port 53.

The problem is related to the fact that Exchange 2000 uses the IIS 5.0 SMTP service. The IIS 5.0 SMTP service uses TCP, rather than UDP, to issue DNS queries. Therefore, to solve the mail domain name resolution problem, you must create a Protocol Rule that allows outbound TCP Port 53.

Problems using complex protocols
The SecureNAT client can take advantage of a wide range of protocols. Commonly used Internet protocols are supported, including:

  • HTTP and HTTPS
  • FTP
  • SMTP
  • NNTP
  • NTP

These protocols (except FTP) are “simple” protocols. Simple protocols do not require that the destination server establish back channels. In contrast, protocols like FTP require that the server establish a back channel to the ISA Server. The connection represents a new inbound request. SecureNAT clients require an Application Filter to access complex protocols.

Application Filters
If you find the SecureNAT client cannot access certain protocols, it is likely that the protocol requires a back channel. The classic example is found with standard FTP PORT commands. After the control channel on TCP Port 21 is established, the FTP server needs to open a new connection from its own Port 20 back to the ISA Server. Without some additional help, the ISA Server will treat this as a “non-ACK” inbound connection and will drop it as an unsolicited request.

To solve this problem, an Application Filter is required. In the case of FTP, ISA Server includes an FTP Access Application Filter. This filter will “listen in” on the conversation between the SecureNAT client and the FTP server, and it will accept the new inbound connection request from the FTP server because it has been made aware of it with the help of the FTP Access Application Filter.

Another example is Napster, which also requires the use of complex protocols. The SecureNAT client cannot access a Napster server using only the Protocol Definitions and Protocol Rules required to access the server. In addition to configuring the Protocol Rule, you must also configure Napster to use the ISA Server’s SOCKS 4 Application Filter.

If your SecureNAT clients experience problems accessing certain protocols, try installing the Firewall client software. If the machine is able to access the protocols after installing the Firewall client, you know that you are working with a complex protocol. In this case, you should leave the Firewall client software on the machine.

Firewall clients manage their own connections

To avoid the problem with complex protocols, consider using the Firewall client software. Firewall clients can manage their own complex protocol connections, and do not always require the use of an Application Filter. You can test this yourself by creating the Protocol Rules required to access Napster and then establishing a connection without using the SOCKS 4 Application Filter. It works because the Firewall client can manage its own connections and does not require the help of the SOCKS 4 filter.

Problems accessing Web sites
SecureNAT clients are able to access Web content either by having requests directly forwarded to the destination Web server or by having the requests go through the Web Proxy service. The advantage of having the requests go through the Web Proxy service is that the SecureNAT client will be able to take advantage of the Web Proxy service’s Web cache. Web objects obtained by the SecureNAT client are also placed in the Web cache. However, problems with Web access are often related to:

  • Configuration of the HTTP Redirector Filter
  • Authentication requirements

Let’s take a close look at these common Web access issues.

The HTTP Redirector Filter
SecureNAT clients are able to take advantage of the Web Proxy service with the help of the HTTP Redirector Filter. This filter is one of the default filters installed during ISA Server setup. Requests for HTTP content are sent from the SecureNAT client to the Firewall service, which then passes the request to the HTTP Redirector Filter. The filter then makes decisions on how to forward the request.

Figure A shows the configuration dialog box for the HTTP Redirector Filter.

Figure A
The HTTP Redirector dialog box

When the Redirect To Local Web Proxy Service option is selected, all requests from SecureNAT and Firewall clients are forwarded to the Web Proxy service. When the Send To Requested Web Server option is selected, the request bypasses the Web Proxy service and is sent directly to the Web server. When the Web Proxy service is bypassed, the SecureNAT and Firewall client will not be able to use the Web Proxy Cache and objects obtained from the Web server will not be placed in the cache.

The last option, Reject HTTP Requests From Firewall And SecureNAT Clients, will prevent HTTP requests from SecureNAT clients from reaching the Internet. If your SecureNAT clients experience problems accessing Web content, check the HTTP Redirector settings and make sure that this last option is not selected.

Authentication problems
SecureNAT clients suffer from a major drawback in that they are not able to send credentials to the ISA Server. Access controls can be placed on a SecureNAT client by creating Client Address Sets. These consist of groups of IP addresses to which access controls can be applied. However, if you require outbound access controls based on user or group information, the SecureNAT client will not be able to fill the bill.

For SecureNAT clients to access HTTP content, you need to have either an anonymous access rule in place that allows all machines access to HTTP, or you must create Client Address Sets and control access by source IP address on the internal network.

The problem is that anonymous access rules for HTTP requests can wreak havoc with an outbound access scheme that is based on user and group credentials. Most secure environments will have both Protocol and Site And Content Rules, which require authentication. User or group-based authentication allows you the most flexibility in terms of outbound access control for HTTP requests.

Since SecureNAT clients are not able to send credentials, all requests that require authentication will be dropped. The only solution for a secure environment that requires outbound access controls for HTTP is to configure the SecureNAT clients as Web Proxy clients as well.

Problems accessing all protocols
There are times when the SecureNAT client will not be able to access the Internet at all. There are a number of reasons why this might happen, including:

  1. The default gateway was improperly set on the SecureNAT client.
  2. The SecureNAT client is not configured with the address of a DNS server.
  3. No Protocol Rules have been configured that allow the SecureNAT client outbound access.

It is important to remember that the default configuration of ISA Server prevents all outbound access for all clients. If you find that your SecureNAT clients are not able to access the Internet right after you install ISA Server, you should create Protocol Rules that will give clients access to the protocols they require.

Default gateway problems pop up most often when the clients are on networks remote from the internal interface of the ISA Server. When you encounter these types of routing problems, check the routing tables on the intermediate routers. Ensure that the routers do not drop requests for nonlocal networks and that they are configured with default gateways that will forward requests for unknown networks to devices that will send the requests to the internal interface of the ISA Server.

Problems with autodial
ISA Server computers support the use of modems and ISDN terminal adapters for an external interface. The dial-up adapter on the ISA Server can be configured to automatically dial up the connection when a request for an Internet resource is requested. However, this is not the default configuration and you may experience problems with autodial for SecureNAT as well as Firewall clients.

To solve the autodial problem for both SecureNAT and Firewall clients, you must configure ISA Server to use the dial-up connection as its primary connection. To do this, perform the following steps:

  1. Open the ISA Server Management console and expand your server or array. Right-click the Network Configuration node and click Properties. You will see the screen shown in Figure B.
  2. Select the Use Primary Connection option and then select the Use Dial-up Entry check box. Click Apply and then click OK.

Figure B
Configuring autodial for SecureNAT clients

After making the configuration change, the SecureNAT client will be able to trigger a demand-dial connection on the ISA Server to the Internet.

In this Daily Drill Down, we examined some of the common problems you’ll encounter with the SecureNAT client. The major problems you’ll encounter with the SecureNAT client will be related to DNS issues and authentication issues. Other problems are related to the HTTP Redirector Filter and dial-up issues. All of these problems are easy to fix once you recognize them.