ISA Clients - Part 1 : General ISA Server Configuration.

ISA server can support three client types; SecureNAT, Web Proxy and Firewall. How well it supports them depends on the infrastructure you provide for ISA to work within. Since ISA operates in conjunction with Windows 2000, you should provide both internal and external DNS servers. That way, ISA can use its favorite name resolution for all names and it and its clients will be all the happier for it. DNS options for ISA server are outlined in this article.

If you’re looking for a tutorial on how to set up the ISA server before you install ISA, then you want this article.

Note: all screen shots in this article are made using the ISA Management MMC in Advanced mode.


Definitions:

• Auto-detection – This is a feature of ISA (WPAD) that allows Internet Explorer (v 5.0 or higher) browsers 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 a bit tricky.
  
• Firewall – This is a LAT host that has the ISA Firewall client software installed, enabled and the application is using it.
  Web Proxy – 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

ISA Server Configuration:
ISA client functionality is heavily dependent on proper configuration of the ISA server itself. If the ISA has difficulty resolving hostnames or reaching the Internet, so will the clients. Test your ISA repeatedly during installation and setup. That way, you’ll know that any change in behavior was probably a result of your last actions.

• Outgoing Web Requests Listener – In order for ISA to function as a Web proxy, the Web proxy service (w3proxy) has to be running and the Outbound Web Requests Listener has to be configured and enabled. To see and change this setup, open the ISA Management MMC and drill down to Servers and Arrays, . Right-click and select Properties. Click the Outgoing Web Requests tab and you’ll be rewarded with something like this:

By default, ISA enables the proxy service on all of the ISA internal IPs at port 8080 (including 127.0.0.1; the localhost IP), regardless of operating (Firewall, Integrated, Cache) mode. That port is used because the ISA Auto Discovery functionality operates at port 80 on all of the ISA internal IPs. To disable the Outgoing Web Requests listener, simply select Configure listeners individually per IP address and don’t select any IPs to listen on.

• Auto Discovery listener – This is one of the great heartaches for folks trying to run IIS and ISA on the same server, even when they limit IIS to the internal IPs. Since no two applications or services may claim the same TCP/IP resources, it becomes a race and the loser gets denied. This is also the source of the dreaded WPAD functionality. Click on Auto Discovery and you’ll see the default settings:

If you don’t need or want Auto Discovery, then just uncheck Publish automatic discovery information. That will free up port 80 on the internal IPs.
Note that ISA can function as a Web proxy server using only one NIC. The only ISA operating mode that supports single-NIC operation is Cache Mode.

• Site and Content Rules – This is where we control HTTP and FTP content that passes through the Web Proxy service. By default, ISA creates a single “Allow rule” that allows any request to pass. You can play all sorts of allow / deny games in here, but be very careful; you can create conflicting rules that will leave your ISA totally blocked.

• Protocol Rules – This is just one of many areas of control within the mind of ISA, but the most easily overlooked. At the bare minimum, you have to allow HTTP and HTTPS in order to have web access for your LAT hosts. There are many more protocols, but without those, you can’t browse the web. You can see that I’ve defined a great many protocol rules for my LAT hosts to use; some of which are custom definitions.

• IP Routing - Next, we make sure that all SecureNAT client traffic flows unimpeded (given the proper rule sets, of course). ISA has a setting called “Enable IP Routing” that is disabled by default. When enabled, this setting allows ISA to pass ICMP (pings) traffic from the LAT to the Internet.
  Open the ISA Management MMC and drill down to IP Packet Filtering. Right-click on it, choose Properties and you’ll be greeted with the following dialog:

The setting we’re interested in is “Enable IP routing”. By enabling this, we allow ISA to use “kernel mode data pumping” to pass traffic. This is explained in KB article Q297347.

• HTTP Redirector – This is where we exercise control over the Firewall and SecureNAT requests for web services. Open the ISA Management MMC to Servers and Arrays, Extensions, Application Filters. Right-click on HTTP Redirector Filter and select Properties. Select the Options tab and you’ll have this:

Here, we can decide how SecureNAT and Firewall client web requests are handled. If you want to force all users through the Web proxy service, then Redirect to local Web Proxy service is your desired choice. You’ll notice that this option also provides us the ability to allow bypassing the Web proxy service should it be unresponsive. This has the benefit of allowing SecureNAT and Firewall clients to still reach the Internet, but it also allows them to bypass the Web Proxy filtering.
Send to requested Web Server allows SecureNAT and Firewall web requests to bypass the Web proxy service all the time. This obviates the use of browser proxy settings fir Firewall and SecureNAT clients.
Reject HTTP requests from Firewall and SecureNAT clients allows you to force the Web proxy settings on your users. No browser settings, no web.

• Local Domain Table – This is critical information for both IE and the Firewall client. Any domain that is entered here causes two things to happen:
  1. Web Proxy and Firewall clients resolve that domain name themselves (not via the related ISA service), if they have a DNS server to query
  2. Web Proxy clients make their requests directly to any server in that domain, ignoring ISA proxy services.

• Name Resolution – The correct IP settings for your ISA server are absolutely critical. At the very least, you have to provide a DNS server for ISA to resolve external FQDN on behalf of Web Proxy and Firewall clients, and you should provide an internal DNS server for the internal network as well. ISA lives on a W2K server and W2K prefers DNS to any other name resolution scheme. Relying on WINS or NetBIOS broadcast name resolution (yuck!) is a sure recipe for intermittent troubles later on.
  ISA provides for its own DNS lookups by creating a DNS Lookup Packet Filter. Make sure you leave this enabled, or ISA may not resolve external names correctly.
  
• Web Proxy and Firewall DNS cache:
  The Web Proxy and Firewall services provide very basic DNS “services” that are totally dependent on the DNS settings made in the ISA IP configurations. They will resolve FQDN requests for Web and Firewall clients using the DNS servers as defined in the ISA IP configuration. Errors here will make name resolution an unholy mess for your Web and Firewall clients. Make sure your ISA server can resolve names properly and quickly!
  The really interesting part is that they have the unique ability to totally ignore the TTL normally associated with the DNS record received from a DNS server. By default, all records held by the Web Proxy and Firewall DNS caches have a TTL of 6 hours, regardless of the actual TTL associated with the record! Needless to say, this can wreak havoc on your client’s name resolution; not to mention any DNS-related testing you may be performing.
  What can we do about this? Plenty. There are two entries in the registry (or Active Directory for Enterprise arrays) for each service in each array that define the size of the DNS cache and the default record TTL. They are:
  
• Web Proxy:
  HKLM\SOFTWARE\Microsoft\Fpc\Arrays\{Array GUID}\ArrayPolicy\WebProxy
  "msFPCDnsCacheSize"=dword:00000bb8
  "msFPCDnsCacheTtl"=dword:00005460
  
• Firewall:
  HKLM\SOFTWARE\Microsoft\Fpc\Arrays\{Array GUID}\ArrayPolicy\Proxy-WSP
  "msFPCDnsCacheSize"=dword:00000bb8
  "msFPCDnsCacheTtl"=dword:00005460
  Note: for Enterprise Arrays, you have to use Active Directory Users and Computers in Advanced view mode, and drill down to System, Microsoft, FPC, Arrays, {Array GUID}, Array policy, etc...

The values are displayed in hexadecimal, but the windows calculator can convert this for you if you set it to “scientific” mode. What they translate to is a default DNS cache of 3K bytes each that allows each record to live for 21,600 seconds (6 hours). While this may seem like an efficient way to make Internet name resolution really zippy for the Web and Firewall clients, it’s also a great way to lock them into some bad data for a very long time. Plus, a “DNS server” that fails to observe the record TTL is non RFC-compliant.
Let’s fix this, shall we?

1. The msFPCDnsCacheSize tells each service how large the name cache is. If you enter 0 in this value, the next registry value is ignored and the service stashes no names. Let’s change this to 0. Now, every name request from a client will be freshly resolved from a real DNS server and the TTL will be correct for that record.
   
2. The msFPCDnsCacheTtl tells the service how long (in seconds) to hold each record it receives. If you allowed any value other than 0 in the previous entry, the value entered here is used. If the previous registry value is 0, this value is ignored
   
3. Now restart the web and firewall services so they can pick up the new settings.

• Web Proxy and Firewall Client Configuration options:
  As the Client Configuration options are specific to the Web Proxy and Firewall Clients, these will be detailed in the articles for those clients.

I hope you’ve found this article both informative and useful. If you have any comments or criticism, please direct them to me.