ISA Clients – Part 2: SecureNAT and Web Proxy Client.

The question of “what kind of client is it?” is a relatively simple one if you ignore the associated questions of “what is it doing?” and “what does ISA provide for that request?”, but we’re not going to do that.

There are three distinct types of ISA clients; SecureNAT, Firewall and Web. Each client type is more a concept than a fact, meaning that it depends on how the LAT host and ISA Server are configured and what the LAT host is trying to do than anything else. Consequently, it’s more accurate to think of them in terms of “client request” than “client”.

It’s entirely possible (and even desirable in some cases) for a LAT host to be configured as a SecureNAT, Firewall and Web client all at the same time. It’s the request and how it’s being made to ISA that determines what kind of client the LAT host is at the time. If you think that’s confusing, read on…

Definitions:

• Auto-detection – This is a feature of ISA (WPAD) that allows certain LAT hosts and Internet Explorer (v 5.0 or higher) to configure themselves to operate properly with the ISA server.
  
• DNS – Domain Name Services; the services residing on a computer that are able to answer a name resolution query. How they answer that query depends on many settings for that server.
  
• FQDN – Fully Qualified Domain Name; this is a computer name that indicates its logical association by virtue of the domain structure associated with the name. For instance, www.microsoft.com indicates a host named “www” that lives in the domain “microsoft” under the top-level domain “com”. These names are always separated by dots “.” and are also known as “dotted decimal”.
  
• GUID – Globally Unique IDentifier; this is a very large number that is guaranteed to be unique. ISA uses these to identify various aspects of its configuration.
  
• LAT host – This is a computer that operates in the subnet that is defined in the LAT. All traffic to and from this host is NAT-ed through the ISA
  NetBIOS name – See “unqualified name”
  
• Record – This is an entry in a DNS zone that represents a single element, such as a host, a mail server or even another zone.
  Secondary Protocol – Any protocol used by an application that differs from the one used to make the initial (primary) connection through the ISA is considered a secondary protocol.
  
• TTL – Time-to-live; indicates how long (in seconds) a name record may live in the requester’s name cache before it must be refreshed
  
• Unqualified name – This is a host name without the form. Also known as the NetBIOS or WINS name.
  
• WINS – Windows Internet Name Services; this is a name resolution service similar to DNS, except that it deals strictly with NetBIOS (unqualified) names
  
• WPAD – Windows Proxy Auto Detection; a feature of ISA that is supported in Internet Explorer 5.0 and higher. When configured properly, it enables IE to configure itself dynamically.
  

ISA Operating Modes:

• Cache – This is the least capable mode, since only the Web Proxy and optionally, the caching services are installed and running. This is also the only mode in which ISA can operate with a single NIC. Only Web Proxy clients are supported in this mode, sine a LAT is needed for ISA to understand SecureNAT and Firewall Clients. This is also the only mode that cannot support the H.323 Gatekeeper service.
  
• Firewall – This is a combination of Firewall and Web Proxy services, without the Web Cache service. All of the main features of ISA are available here and all client types are supported. ISA must have at least two NICs to operate in this mode; one external, one internal (LAT).
  
• Integrated – This is the full-blown, all-out, feature-packed installation; Web Proxy, Firewall and Web Caching are all together having a great big packet-munching party just for your pleasure. The only real difference between this and Firewall mode is the Web Caching service.
  

ISA Clients:

• SecureNAT – This a LAT host that has a default route through the network to the ISA as its only means of Internet communication. In a simple network (no routers), this client has the ISA primary internal IP as its default gateway. In a complex (routed) network, this gets tricky.
  
• Firewall – This is a LAT host that has the ISA Firewall client software installed and enabled
  
• Web – This is simply an application (IE or other web-enabled application) on a LAT host that uses proxy requests to the ISA outbound web listener IP and port to reach the Internet
  
  
  Feature Comparison

Notes:

1. Any application running on a LAT host can be a Web Proxy client if:
   a. The application (browser, FTP client, etc.) is CERN-compatible, that is, it understands the proper method of making a proxy request
   b. It provides a means for you to specify the name or IP address AND the port to use for proxy requests
   
2. ISA auto-detection for Web Proxy clients is limited to Internet Explorer version 5.0 and later and is very sensitive to internal name resolution issues
   
3. ISA auto-detection for Firewall clients is very sensitive to configuration issues, especially name resolution settings
   
4. Limited to HTTP, HTTPS and FTP download only
   
5. Can use any simple protocol (no secondary connections) according to the Protocol and Site and Content rules defined in ISA
   
6. Can use all protocols not specifically denied by ISA

SecureNAT Client:
This client can be running any operating system that understands TCP/IP networking and is the simplest of all to configure; merely place the primary internal IP of the ISA server in the default gateway of the client’s IP settings, configure the proper protocol definitions and rules in the ISA and you’re off to the races…Or are you? Here are some things that affect SecureNAT client functionality:

• ISA server operating mode(s) that supports this client – Firewall, Integrated. Note that Cache mode is not listed here. That’s because SecureNAT clients need to use ISA as a router and that functionality just doesn’t exist in cache mode, regardless of how many NICs you throw at the ISA server. The Firewall service has to be installed and running on the ISA before a SecureNAT client gets out.
  
  
  
• ISA Server Client Configuration options:
  Other than the “Enable IP routing” setting, there aren’t any, really… The SecureNAT client is a unique beast in that ISA has no specific knowledge of it, except in the context of the IP address and protocol it uses. ISA either allows the protocol that the SecureNAT client wants to use, or the traffic never flows. To set a W2K client for proper SecureNAT functionality, right-click My Network Places, select Properties. Right-click Local Area Network (assuming you only have one) and select Properties. Scroll down to Internet protocol (TCP/IP), select it and click the Properties button. You’ll see something like this:
  
• 
  
  
  
  The entries found here are the minimum required for any client to function in a TCP/IP network; the key point here is that for SecureNAT functionality, the ISA must be the default route to the Internet for this client. If you’re operating in a routed network, then read this article. All these settings can be assigned using DHCP, if desired.
  
  
  
  
• Name Resolution – The correct IP settings for your SecureNAT client are completely dependent on the environment in which it lives. Name resolution for Internet requests is a primary consideration here, since this type of client request doesn’t use the ISA Web Proxy or Firewall services’ DNS “feature”. You have to either provide an internal DNS server that can resolve Internet names, or allow the SecureNAT client to make its own resolution requests through ISA. Either way, ISA has to allow those requests to the Internet.
  Create a protocol rule called “Internet DNS” (or George, if you prefer) that allows both DNS Query and DNS Zone Transfer protocols.
  Using the isaserver.org tutorial as a guide, create a protocol rule that allows DNS Query and DNS Zone Transfer protocols. Don’t select the Server versions of these protocols; they’re only for server publishing and have no bearing on outbound requests.
  
  
  
• User Authentication – SecureNAT clients cannot authenticate to ISA at all. If ISA requires authentication for the request being made by the client, the user will either see an authentication popup or a failure to connect, depending on the application or service making the request and the authentication technique applied to the request.
  
  
  
• Protocol availability – SecureNAT clients can only use those protocols that are:
  1. Simple protocols (no secondary connections)
  2. Listed in Policy Elements, Protocol definitions
  3. Allowed in Access Policy, Protocol Rules
  4. Not restricted by user or group through Access Policy, Site and Content Rules
  
  
  
• Web Proxy Client:
  This is one that creates confusion for many folks, since it’s not the LAT host configuration as much as the request made by the application it runs that makes it a Web Proxy client. The host itself can be a SecureNAT client, Firewall Client, or both; it doesn’t matter. If the application makes a proper proxy request to the ISA server Web proxy service, it’s a Web Proxy client and is subject to the rules and limitations of that service.
  
  
  
• ISA server operating mode(s) that supports this client – All
  
  
  
• ISA Server Client Configuration options:
  Open the ISA MMC and drill down to Client Configuration. Right-click Web Browser and select Properties; select the Direct Access tab and you’ll have the following dialog. Here is where we define some of the IE settings that invisibly change the settings normally found in the Connection tab of IE. All of the data here is sent to IE as a Jscript if it makes a request to ISA using either the http:///array.dll?Get.Routing.Script or http:///wpad.dat request.

• Bypass proxy for local addresses – this does exactly what it sounds like; it instructs IE to directly contact the desired resource if it is considered “local”. “Local” is defined as any domain in the LDT or any unqualified name request. For instance, http://thatserver would be considered local, while http://thatserver.domain.tld would be considered local ONLY IF the domain was listed in the LDT.
  
  
  
• Directly access computers specified in the Local Domain table (LDT) – this setting, if unchecked, allows IE to make proxy requests for LDT-based servers, while maintaining the “local” setting for unqualified requests. Since this would be a waste of ISA’s time and resources, keep this checked.
  
  
  
• Directly access these servers or domains: – this setting allows you to specify specific servers or domains that should be directly accessed as exceptions to the first two rules. If the domain is an external one, IE expects to operate as a SecureNAT or Firewall client for this request.

Now select the Backup Route tab. This setting allows IE to use an alternate means to reach the Internet if the primary ISA server is unresponsive. There are two options:

• Direct Access – this allows IE to make requests as a SecureNAT or Firewall client, assuming that the network infrastructure has been built to accommodate that.
  
  
  
• Alternative ISA Server – this allows ISA to use a secondary ISA if the primary fails. This ISA server must exist, of course, and using the primary as the secondary is a waste of time, since the primary has to be unresponsive for this option to be considered by IE.
  
  
  
• Client application settings – Since Internet Explorer is the most common Web Proxy client, we’ll use it for our example. We’ll start with the main connectivity settings; you get there by either right-clicking the Internet Explorer icon on the desktop and selecting Properties, or if IE is already running, you select Tools, Internet Options. From there, select the Connections tab and then click the LAN Settings button. There are four basic options here:
  

• Automatic Configuration – the settings made here are used first, making web access a chore if you’ve either misconfigured ISA or DNS.
  
  
  
• Automatically detect settings – this is completely dependent on the Auto Discovery feature being enabled, and also having the WPAD entry in the internal DNS zone. If you don’t have internal DNS or DHCP with option 252 defined, turn this off. Also, if you’re using a version of IE older than 5.0, or any other browser, this isn’t going to work. Remember, the client can’t use the ISA Auto Detection feature until it can resolve the ISA server name to begin with.
  
  
  
• Use automatic configuration script – This allows the browser to query the ISA server for a Jscript that will allow it to configure itself for proper operation with the ISA server. The data that comes as part of the script is derived from the settings found in the LDT and the Web Proxy Client Configuration options.
  
  
  
• Proxy Server – the settings made here are used only if the automatic settings fail or there are none entered.
  
  
  
• Use a proxy server for your LAN (These settings will not apply to dial-up or VPN connections) – note the disclaimer for this setting. Here’s what bites many an unwitting ISA user when they’re using a VPN connection behind an ISA. There is a whole other set of settings for each dial-up or VPN connection that allows IE to use whatever proxy services may be available there.
  
  
  
• Use automatic configuration script – This allows the browser to query the ISA server for a Jscript that will allow it to configure itself for proper operation with the ISA server. The data that comes as part of the script is derived from the settings found in the LDT and the Web Proxy Client Configuration options.
  
  
  
• Internet Explorer on the ISA Server may also function as a Web proxy client by making the following settings in IE Properties, Connections, LAN Settings:

This has the effect of causing IE to look to the local machine to make proxy requests. Since ISA binds the Outgoing Web Requests listener to all internal IP addresses and localhost resolves to a valid IP (127.0.0.1, an internal IP), it will serve IE as if it were a LAT host. Notice that we’re still able to use the Use automatic configuration script just like any other LAT host and the best part is that it will work!
It is also possible to allow the ISA server IE web access by removing the proxy settings and defining a packet filter that allows TCP-80 outbound, but you also lose logging for those connections when you do that. This can make troubleshooting difficult. On the other hand, it also bypasses the Web Proxy DNS functionality, making it a useful troubleshooting technique. The scenario should dictate which option you choose.

• Name Resolution – By default, the Web Proxy service offers simple DNS functionality to Web proxy clients. By default, Web proxy clients use this functionality. As long as the ISA server can resolve Internet names, the client application can, too. Bear in mind, though that this functionality does not extend to unqualified names; they are resolved by the LAT host using whatever mechanisms are available to it.
  
  
  
• User Authentication – Web Proxy clients are able to authenticate to the ISA server using Integrated (NTLM), Basic (HTTP) or Digest (W2K AD only) authentication. Only Windows clients can use Digest authentication, since it depends on W2K AD functionality.
  
  
  
• Protocol availability – Web Proxy clients can only use HTTP, HTTPS, Gopher and FTP download only protocols and they must be allowed in Access Policy, Protocol Rules
  
  
  
• Content availability – Determined by the rules defined in Access Policy, Site and Content Rules

That’s it for today; feel free to contact me with comments.