The Definitive Guide to ISA Firewall Outbound DNS Scenarios Part 2

If you would like to read the other parts in this article series please go to:
The Definitive Guide to ISA Firewall Outbound DNS Scenarios Part 1
The Definitive Guide to ISA Firewall Outbound DNS Scenarios Part 3
The Definitive Guide to ISA Firewall Outbound DNS Scenarios Part 4


In the first part of this definitive series on outbound DNS access through ISA Firewalls, I went over the process of DNS name resolution for Internet based host names. We spend most of our time going over the process of recursion and how recursion is used to contact a number of Internet based DNS servers to resolve Internet host names. We also discussed how DNS forwarders work and how by combining DNS forwarders with DNS caching we can greatly improve the process of DNS host name resolution.

Discuss this article

In the second part of our three-part series, I will focus on how various ISA Firewall client types resolve host names. This is a very important part of your outbound DNS name resolution infrastructure and a strong understanding of how the different ISA Firewall client types resolve names will help you set up a good design from the start and help you resolve name resolution and performance issues in the future.

The two main topics of discussion today are:

  • How clients behind the ISA Firewall resolve DNS host names
  • Direct Access configuration for Web proxy and Firewall clients

How Clients Behind an ISA Firewall Resolve Host Names

Before getting into the DNS infrastructure scenarios, it is a good idea to understand how the various ISA Firewall client types resolve Host names, both for internal and external resources. There are three ISA Firewall client types:

  • The SecureNET (SecureNAT) client A SecureNET client is a machine configured with a default gateway address that allows Internet bound requests to pass through the ISA Firewall. If the SecureNET client is located on the same subnet of the ISA Firewall, then the default gateway address will be IP address of the ISA Firewall’s interface on the same network ID as the client. If the clients are on a remote subnet from the ISA Firewall, then the IP address will be a router interface address that will use route outbound requests through the ISA Firewall. While the “official” name in the ISA Firewall documentation is SecureNAT client, it is more accurately referred to as a SecureNET client because the Network Rule defining the connection between a source and destination network does not have to be a NAT relationship, it could be a Route relationship.
  • The Firewall Client The Firewall client is a piece of software that must be installed on the client operating systems (the Firewall client should not be installed on server operating systems and never on the ISA Firewall itself). The Firewall client is a generic Winsock proxy client that intercepts Winsock application network calls and forwards them (remotes them) directly to the ISA Firewall. This enables the Firewall client to be transparent to the network routing infrastructure and does not depend on default gateway or route of last resort configuration on network routers. The only network infrastructure requirement is that the clients have a route to the IP address of the ISA Firewall closest to the client. The Firewall client also enables user authentication for access control and supports secondary connections for complex protocols when there is no Application Filter to provide that support. In contrast, SecureNET clients must have an Application Filter in place to support complex protocols that may require multiple primary and secondary connections.
  • The Web Proxy client The Web proxy client is a machine that has its browser configured to use the ISA Firewall as its Web proxy device. Browser configuration can be done manually, or can be automated using the WPAD protocol and WPAD entries in DHCP and/or DNS. The Web proxy client configuration supports only HTTP, HTTPS, and HTTP tunneled FTP requests and does not support FTP upload, only FTP download. Web proxy clients can authenticate with the ISA Firewall, in contrast to SecureNET clients, which cannot authenticate with the ISA Firewall.

The client types should actually be seen as client “roles”, as a single machine can be configured as a SecureNET, Firewall and Web Proxy client. However, a single machine cannot act in multiple roles on a per application basis and any single point in time.

For example, a machine configured as a SecureNET client and a Web proxy client is not going to simultaneously act as a Web proxy and SecureNET client when connecting to a Web site – it will act as either a SecureNET client (if Direct Access is configured for that site) or a Web proxy client (if Direct Access is not configured for that site). We’ll talk more about Direct Access later in this article.

The next question to be answered is how to the various client types resolve host names?

  • Name resolution for SecureNET clients. SecureNET clients must be able to resolve host names on their own using the DNS server configured on the SecureNET client’s network interface.
  • Name resolution for Firewall clients. When the Firewall client software handles a connection made by a Winsock application on the Firewall client computer, name resolution is by default handled by the ISA Firewall. In this case, the ISA Firewall must be configured with a DNS server on its internal interface that can resolve host names.
  • Name resolution for Web Proxy clients. When a Web proxy client handles a connection request for a Web proxy enabled application, name resolution is handled by the ISA Firewall. In this case, the ISA Firewall must be configured with a DNS server on its internal interface that can resolve host names.

When the ISA Firewall handles requests for Firewall and Web Proxy clients, the ISA Firewall assumes that you want to go through the ISA Firewall to reach those resources. There may be times when you want to bypass the Web Proxy and Firewall client configuration so that you can make a direct connection to the resource and not bounce back through the ISA Firewall. For example, consider the situation in the figure below.


Figure 1

The following sequence of events helps highlight the issue:

  1. A Firewall or Web Proxy clients makes a request for a resource that is located on the same ISA Firewall Network as the client making the request.
  2. The ISA Firewall proxies the request made by the Firewall or Web proxy client to the resource located on the same ISA Firewall Network that the client is located on.
  3. The response from the resource is returned to the ISA Firewall, since the ISA Firewall is acting as a proxy between the client and the network resource.
  4. The response is returned from the ISA Firewall to the client making the request.

As you can see here, there is the potential for generating a great amount of network traffic through the ISA Firewall for resources located on the same ISA Firewall Network. This has the potential of bogging down the ISA Firewall to a standstill and for no good reason, since the ISA Firewall should never been seen as a “go between” between clients and servers located on the same ISA Firewall Network. Instead, clients and servers located on the same ISA Firewall Network should connect directly to one another. This is referred to as Direct Access. Direct Access can be configured separately for Firewall and Web Proxy clients. When Direct Access is enabled, the Web Proxy and/or Firewall client configuration is bypassed.

When you configure Web Proxy and/or Firewall client direct access the following happens:

  1. When the Web Proxy or Firewall client makes a request for a resource contained on the Web Proxy or Firewall client Direct Access list, the Web proxy or Firewall client configuration is bypassed to access that resource. When the Firewall client or Web Proxy client configuration is bypassed, the client computer then becomes responsible for resolving the host name itself. The client sends a DNS query request for the destination server name to the DNS server configured on the client’s interface.
  2. The DNS returns the address of the destination server to the client.
  3. The client makes a request directly to the destination server, bypassing the Firewall and/or Web proxy client configuration.
  4. The Destination server sends responses directly back to the client.

Discuss this article

Direct Access Configuration for Firewall and Web Proxy Clients

Direct Access is such an important topic that I think we should take a few minutes to discuss it now. Remember, when you configure a site for Direct Access, you are configuring connections to that site to bypass the Firewall and/or the Web Proxy client. When you bypass these client configurations, the client system must have a method to connect to the destination, which is typically the SecureNET client configuration, unless the connection is to a resource on the same ISA Firewall Network as the client, in which case the connection is made directly to the resource and does not traverse any routers or firewalls.

In the figure below you see the Properties dialog box for the default Internal ISA Firewall Network. On the Domains tab, you enter the domains for which you want the Firewall client settings to be bypassed. Typically, these are domains that are located on the same ISA Firewall Networks as the clients, but that does not always have to be the case. You might want to bypass the Firewall client configuration to reach an external resource, or a resource that is located on another ISA Firewall Network and so the connection attempt has to be made through the ISA Firewall.

Keep in mind that when you bypass the Firewall client to reach these domains, the client will need to leverage either its SecureNET or Web Proxy client configuration to reach resources on these domains. If the SecureNET client is the only option left to the client system to connect to the destination, then you have to make sure that there is an Access Rule that does not require authentication to allow access, since SecureNET clients are not able to authenticate.


Figure 2

The figure below shows the Web Browser tab in the Properties dialog box of the default Internal ISA Firewall Network. This is where you configure Direct Access settings for Web Proxy clients. There are several options here and they are commonly misunderstood. These are:

  • Bypass proxy for Web servers in this network This is a very misleading description, since it has nothing to do with whether or not computers happen to be on the same ISA Firewall Network. What this option means is that the Web proxy client configuration should be bypassed when a user connects using a single label name, such as http://server1. In general, you should not be using single label names, so whether you enable this one or not is up to you. I usually leave it enabled.
  • Directly access computers specified in the Domains tab This option disables the Web proxy client configuration for domains that are specified on the Firewall client’s domains tab. You should leave this one enabled.
  • Directly access computers specified in the Addresses tab The Addresses Tab contains the addresses that define this ISA Firewall Network. You should always use Direct Access when connecting to resources on the same ISA Firewall Network as the client, so this option should always be enabled.
  • Directly access these servers or domains If there are other servers or domains that you want to use Direct Access for, then you would use the Add button and add them here. This is where you would enter the names of the Internet sites that do not work with Web proxy servers, such as many Java sites. Any time you have a problem with a Java application or other poorly coded Web site that does not work with CERN compliant Web proxy servers, you should enter that site here. Be aware that since ISA 2004 SP2, you cannot mix both IP addresses and domain names on this list. I recommend that you use only domain names on this list.
  • If ISA Server is unavailable, use this backup route to connect to the Internet This is another one of those misleading options that is not exactly what it says it is. What this option means is that if the Web proxy service is not available on the ISA Firewall, what should the Web proxy client do to access the Internet? You have to option to putting in the name of another Web proxy server, in which case the Web proxy client will access the Internet through the alternate Web proxy server, or you can select the Direct access option, which means the Web proxy client configuration will be disabled and the client will have to leverage it’s Firewall client and/or SecureNET client configuration to reach the Internet for Web resources.

It is vital that you be aware that autodetection must be working for the Firewall client Direct Access list to work. This is not a problem since if the Firewall client cannot detect the ISA Firewall, the Firewall client will not work at all and you will have to immediately troubleshoot the reason for the failure. On the other hand, in order for the Web proxy client to get the Direct Access list, you must configure the Web proxy clients to either use WPAD based autodiscovery, or you need to configure them to use the autoconfiguration script, which can be done either manually or via Group Policy.


Figure 3

So to quickly summarize:

  • SecureNET clients always resolve names on their own. The ISA Firewall never resolves names on behalf of SecureNET clients.
  • Web proxy clients always allow the ISA Firewall to resolve names on their behalf. The exception to this rule is when the Web proxy client configuration is bypassed because the destination site is on the Direct Access list
  • Firewall clients by default always allow the ISA Firewall to resolve names on their behalf. The exception to this rule is when the Firewall client is connecting to sites on its Direct Access list.
  • When you find that your Web proxy and Firewall clients can connect to the Internet and the SecureNET clients cannot, the most likely reasons for this is that there is not a rule that allows anonymous access to the destination, or the SecureNET client cannot resolve the name for the destination it is trying to reach.

Discuss this article

Summary

In this article we went over how the various ISA Firewall client types resolve names. By default, SecureNET clients must be able to resolve names on their own with no help from the ISA Firewall. Web proxy and Firewall clients allow the ISA Firewall to resolve names on their behalf. There are times when you need to bypass the ISA Firewall or bypass an ISA Firewall client type in order to connect to a resource. In this case, you configure the Firewall or Web proxy client to use Direct Access. When Direct Access for a site is indicated, the client type for which Direct Access is configured is bypassed, another client type (or client “role” as we discussed earlier) is used. Knowing how ISA Firewall client types resolve Internet host names and how to use Direct Access will help you build a more robust name resolution infrastructure and help you troubleshoot many name resolution and performance problems related to the ISA Firewall.

Next week we will go over the various outbound DNS scenarios and how you can use them in your organization.

See you then! – Tom

If you would like to read the other parts in this article series please go to:
The Definitive Guide to ISA Firewall Outbound DNS Scenarios Part 1
The Definitive Guide to ISA Firewall Outbound DNS Scenarios Part 3
The Definitive Guide to ISA Firewall Outbound DNS Scenarios Part 4


Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top