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 packetmunching 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.
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
Client WEB SecureNAT Firewall
Settings App or browser proxy settings = ISA outbound web requests listener IP (or name) and port Default Gateway = ISA primary internal IP ISA Firewall client (or Proxy 2 client) installed on LAT host
ISA Op Mode All FW, Integ FW, Integ
Non-MS ISA Auto- Avail host Detect Proto 1 Y N 2 N 3 4 5 6
Sec Proto N N Y
Client Auth Y N Y
ISA as DNS Y N Y
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 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 ISA auto-detection for Firewall clients is very sensitive to configuration issues, especially name resolution settings
2. 3.
4. 5. 6.
Limited to HTTP, HTTPS and FTP download only Can use any simple protocol (no secondary connections) according to the Protocol and Site and Content rules defined in ISA 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