ISA Clients – Part 3: The Firewall 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”.
FWC – Firewall Client; what I use in this article to indicate the FWC software on the LAT host itself
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.
VIP – Virtual IP; this is a valid IP address that is assigned to either an NLB cluster or a hardware load-sharing device.
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.
WSPAD – Windows Sockets Proxy Auto Detection; this is the P2 legacy file that was replaced in ISA with mspclnt.ini. It still works for P2 legacy server publishing.

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, since a LAT is needed for ISA to understand SecureNAT and FWCs. 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 FWC installed and enabled and the application is making Winsock requests through it. If the app doesn’t use the FWC software, it’s not a Firewall
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 FWC’s 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

Firewall Client:
This client is the most capable of all, because it has the unique ability to decide on a “per-application” basis how it will act and what information the application has to operate with. Additionally, it is the only client that is able to use secondary protocols. It’s the need for secondary protocols that make the FWC necessary for apps like Instant Messaging, streaming media, FTP, etc. This is also the most difficult client for most folks to get their minds around, since it is so “application-configuration” dependent.

• ISA server operating mode(s) that supports this client – Firewall, Integrated. Note that Cache mode is omitted. This is because Cache mode does not install the Firewall service, which is required for Firewall and SecureNAT clients’ functionality.

• Name Resolution – This gets really interesting, because there isn’t a “right answer” for how Firewall Clients resolve names. They can use the ISA Firewall service DNS functionality or they can act like SecureNAT clients and resolve qualified names themselves. It depends on the settings in the Client Applications section (discussed later). Either way, they always resolve unqualified names without using the ISA server firewall service.

  
  

• User Authentication – Firewall Clients, like Web Proxy clients, can authenticate to the ISA server, providing the credentials of the interactively logged-on user, or as specified using CredTool.exe.

• Protocol availability – Firewall Clients can use those protocols that are:
  1. allowed in Access Policy, Protocol Rules
  2. not site-limited by Site and Content Rules
  3. defined as having secondary connections

• Configuration Files – two files combine on the Lat host at \Program Files\Microsoft Firewall Client\internal_setup\ to define the settings for the FWC software and how it responds to Winsock requests from applications and services:
  mspclnt.ini; this file contains the bulk of the configuration data and is representative of the contents of wspad.dat
  msplat.ini; it contains all entries made in Network Configuration, Local Address Table, and resides separately on the client to maintain compatibility with the Proxy-2 form of the wspcfg.dat file. This file also contains two other subnets:
  224.0.0.0-255.255.255.254 this is the standard multicast subnet. Since ISA doesn’t pass multicast traffic, this has to be defined as local.
  127.0.0.0-127.255.255.255 this is the standard “localhost” address set. None of the addresses in this range are valid outside the host that’s running TCP/IP, so they should never be seen by ISA.
  Both of these files are sent to the ISA server during FWC installation. When the user clicks the Update Now button on the FWC configuration dialog, these steps occur:

  1. The FWC makes a call to http:///wspad.dat to obtain the settings that are saved as mspclnt.ini if the “Enable ISA Firewall automatic discovery in Firewall Client” checkbox is selected.

  2. The FWC then makes a connection to the ISA at TCP-1745 to obtain the data for msplat.ini and another grab at the data for mspclnt.ini at the same time.
  Bear in mind that weak internal name resolution can cause this process to be painfully slow or cause it to fail altogether.

  
  

• ISA Server Settings – There are quite a few settings in ISA that apply to the FWC. If you’re interested in settings made at the client itself, then I’ll refer you to this article. What we’re interested in here is how to create settings that allow the FWC to operate properly with ISA and specific applications function properly as a FWC app.

  • The first place to go iso Client Cnfiguration, Firewall Client. It’s here that all the settings are made to change how the client app and ISA interact through the FWC software:

    
    

  

If you double-click on Firewall Client, you’ll see the following “properties” dialog:

Here is where you can make or break ISA FWC functionality. Everything you enter here determines the default settings for the FWC when it’s installed on the LAT host, as well as the data passed when the FWC asks for a refresh from ISA.

• DNS name: the NetBIOS name of the ISA server is entered for you by default. Unless you’re implementing a DNS round-robin scheme for internal load balancing or something similar, leave it alone. It’s where the FWC software seeks out its settings, so unless you know for certain that the name entered here doesn’t suit your scenario, leave it alone! You can change this at the client, but the ISA-owned setting is passed in the wspad.dat when the FWC refreshes its settings.
• IP address: You can enter the IP address of the ISA server if you either don’t have any internal name resolution services (WINS, DNS).
• Enable ISA Firewall automatic discovery in Firewall Client – this setting doesn’t control whether or not the FWC is allowed to auto-detect the ISA server, just whether or not it’s configured to do so by default. This setting is also changeable at the client itself.

  • Now click on the “Application Settings tab; here is where you make or break your Winsock-compatible applications with ISA Server FWC

    
    

  

  
  
  

What we’re not going to do here is duplicate the efforts of the ISA documentation team. There are some really good explanations in the section labeled Configuring Firewall client settings. What I do intend to do is expand on some of the less-than-clear areas of those explanations and give you some idea how they affect real-world issues. Dig out your help files, boys and girls; we’re gonna use ‘em today.

Open your ISA help and seek out the section titled Firewall client application settings. You’ll notice the reference to the wspcfg.ini file; it and the mspclnt.ini files are essentially the same thing, since they contain the same data. The difference between them is how they’re used.

– mspclnt.ini; the help covers the purpose and uses of this quite well, except that a very useful section is missing; [Common Configuration] (we’ll get to that later when we go over the individual application settings).
– wspcfg.ini; this file is specific to the Proxy 2 form of server publishing, where the proxy client software had to be installed n the published server. It also serves to maintain compatibility with the Proxy 2 client, since it wouldn’t understand hot to ask for or use the mspclnt.ini.. Since ISA normally requires that all server-published services reside on a SecureNAT host, this publishing technique is required if the published server cannot be a SecureNAT client.

Each application defined in the FWC app settings gets its own subheading as [Application_Name]. The name of the application is derived from the name it reports to the OS while it’s running. For instance, Outlook Express identifies itself to the OS as “msimn.exe” and MSN Instant Messenger appears as “msmsgs.exe”. This information is critical if you expect to see any change in FWC behavior with respect to your app based on the following settings. If you have any doubt as to how the app identifies itself, open Task Manager and watch the applications tab as you start your program. Generally, it’ll be the name of the executable as it appears in Windows Explorer.

• Disable; to be clear, this setting disables the FWC for the specified app, not that the specified app is denied TCP/IP functionality. In other words, the FWC doesn’t exist as far as this app is concerned and the app or service has direct communications with Winsock if it desires.
• NameResolution; as stated in the help, this setting defines what the default name resolution behavior is for the FWC client app. This only applies to qualified names (DNS names, or FQDN). Unqualified names (NetBIOS or WINS names) are always resolved by the LAT host TCP/IP stack.
• LocalBind(Tc/Ud)pPorts; this setting defines a list or range of ports that are bound at the LAT host at 0.0.0.0:. This binding can be thought of as “global”, since it effectively binds to any IP owned by the LAT host. Under some circumstances, this can become an implicit RemoteBind operation if a packet is sent immediately after the bind operation.
• RemoteBind(Tc/Ud)pPorts; this setting defines a list or range of ports that the app binds to on the ISA server at 0.0.0.0:. This also binds the same port to the LAT host at 0.0.0.0: and establishes a communications link between them. Kewl, huh?
• ServerBindTcpPorts; this setting is the same as RemoteBind, except that it allows multiple external connections through ISA to the client. This is effectively the same as server-publishing that TCP port to the LAT host as if the LAT host were a SecureNAT client. Note that there is no ServerBindUdpPorts. This is because UDP is “connectionless”; it’s just a data stream. Consequently, there is no gain to defining that port as “ServerBound”.
• ProxyBindIp; this setting is pretty clearly explained. Essentially, it “reserves” an IP/port combination for a particular client. The thing to bear in mind when choosing this option is that it:

  • is a universal setting that applies to TCP and UDP ports at the same time.
  • precludes another app or service using that IP/port combination.
    These are important points because you can’t see that these connections exist in the ISA MMC Monitoring, Sessions window. Trying to publish a server on the same IP/port pair under these circumstances can cause much hair loss.
    

• KillOldSession; this is pretty clear; only one session is allowed for any given service or app from a single client if this is defined as “1”
• Persistent; the opposite of KillOldSession, this allows a bind to remain active even if the service or app loses communications with the ISA. This allows it to “reclaim” its previous connection if it crashed.
• ForceProxy; this setting forces a particular app to use only one ISA server, even if NLB or other load-balancing technique is being used. Using this setting, you can guarantee that any traffic to/from this service or app will always be seen by a particular ISA server. Obviously, if you only have one ISA, this setting is pretty useless.
• ForceCredentials; this setting allows the service or app to communicate with ISA using the credentials specified for that app or service using the CredTool.exe. This allows you to specify “must authenticate” for all protocols and still have your published server operate normally. Details of CredTool.exe will be detailed later
• NameResolutionForLocalHost; this setting defines how the FWC reports the IP address of the LAT host to the requesting app for a GHBN Winsock call. Many times, a Winsock-compatible application needs to know its own IP address so that it can provide that information to another client, to establish a connection between them. If the app running on a LAT host reports an internal IP to the remote client, then no communication can take place. If the FWC reports the ISA external IP and all other settings support that communication, then the two apps can chat all day long.
• ControlChannel; this setting defines whether the client app uses UDP or TCP to control the session with ISA.

You may have noticed while reading carefully in this section of the ISA help, that [Common Configuration] is stated as one of the places the FWC looks to for information. If you’re even more observant, you’ll also notice that it doesn’t exist in mspclnt.ini by default. When you enter an application name and that application is unknown to ISA, a new section is created in the ISA version of mspclnt.ini as [AppName]. This is also how you would create the [Common Configuration] section; by entering “Common Configuration” in the Application Name as shown below:

You may have noticed that I’ve used the NameResolution=L entry here. Why would he do that, you may ask? ..it’s OK; you can, I don’t mind… What this setting will do is cause the FWC to refer to the LAT host DNS client service for any and all FQDN resolution requests except where specified differently for a particular app or service in the mspclnt.ini file. If you have a solid DNS-based name resolution structure (NetBIOS broadcasts don’t count), then this setting will help you avoid the FWC DNS cache of death as mentioned in part one of these articles. I highly recommend using this setting (hint-hint). It can also mean the difference between an ISA event log full of 14120 errors and a peaceful ISA server (another article, RSN).

Now open your ISA help and seek the section titled Configuring Firewall client settings. This is the section that defines the basic functionality for the FWC and is presented as the first part of mspclnt.ini.

• Master Config; this is pretty clear, so I won’t waste your time
• Server IP Address(es); The two possible entries here; Name and Addr1 are mutually exclusive; only one of them will exist in this section. Here is where you can support firewall load-balancing via DNS round-robin or NLB across an array by using a “global name” or “global IP address” for all servers in the array. Actually setting that up is a subject for another article, though.
• Common; Lots of entries here that have everything to do with how ISA and the FWC LAT host cooperate. Most of these entries can be changed in the ISA MMC, but some require manual editing of the ISA mspclnt.ini file.

  • Port – under normal circumstances, there should never be a reason to change this value. Don’t play with it unless you absolutely have to or unless you have more hair than you need.
  • Configuration Refresh Time – Also clear in the help. If you make lots of changes over a short period of time, you may want to tweak this setting. You may also wish to experiment with a non-production server so as not to anger the boss and your coworkers.
  • Re-check Inaccessible Server Time (Minutes) – also clear in the help; part of the configuration recheck settings.
  • Set Browsers To Use Proxy – this is actually a setting derived from the Web Browser section of Client Configuration and does exactly what the help says.
  • Configuration URL – also derived from the Web Browser section of Client Configuration
  • Local Domains – this is from data entered in the LDT, but can be modified manually. As stated in the help, these names are resolved locally and the servers contacted without using the ISA as a proxy
  • WWW-Proxy – also derived from the Web Browser section of Client Configuration
  • WebProxyPort – this is derived from the HTTP port setting in the Outbound Web Requests tab of the Server or array properties.
  • Set Browsers to use Auto Config – also part of the Web Browser section of Client Configuration
  • AutoDetect ISA Servers – this value is based on the FWC Enable ISA Firewall automatic discovery in Firewall Client setting.
  • Set Browsers to use Auto Detect – also part of the Web Browser section of Client Configuration, but differs from Auto Config in that this is the WPAD part of ISA

• LAT Host Settings – not many things I can cover here that aren’t already covered in this article. I will take on a short trip through the CredTool.exe application, as promised, though

CredTool.exe; is a totally useful little app that allows you to run a service or app in the context of a particular user, but only for purposes of interacting with ISA via the Firewall Client. This means that any call made to ISA by the FWC on behalf of the application or service does so with the credentials you specify when you run the tool. It’s a nice piece of functionality to have around when you need to lock everything through the ISA to user / group permissions. Here’s how you use it…

Open a command window and “cd” to \program files\microsoft firewall client. From here, you can run “credtool /?” and be rewarded with a listing of the options and what they do for you.

D:\Program Files\Microsoft Firewall Client>credtool /?
Bad parameters
Usage:
CREDTOOL [-r|-w|-d] -n appname [-c User Domain Password]
-r reads the credentials
-w writes, or stores the credentials
-d deletes the credentials
-n appname specifies the name of the application executable
file without the extension
-c user domain password specifies the account credentials

For example, if we want the DNS service to be a firewall client-published app because our network doesn’t allow us to use SecureNAT, we would install the Firewall client on the server and copy the mspclnt.ini to the folder where dns.exe lives (%Systeroot%\system32 by default) as wspcfg.ini.
Then, we would change folders to \program files\microsoft firewall client and run credtool.exe with the following parameters (replace UserName, DomainName and PassWord with appropriate user credentials):

D:\Program Files\Microsoft Firewall Client>credtool -w -n dns -c UserName DomainName PassWord
Write credentials for [dns]
User: [UserName]
Domain: [DomainName]
Password: [PassWord]

The credentials are then applied to any request made to the ISA only on behalf of this service, allowing all protocols to be user-authentication controlled.
Note: the “DomainName” section must be specified. If you don’t operate a domain (NT4 or W2K AD), then you must specify the machine name where the user account resides. Since ISA must hold all user accounts in non-domain (Workgroup) environment, you should use the ISA server NetBIOS name as the “DomainName”.

To remove or read the credentials assigned to a given app or service, you need only specify the operation (-w or –r) and the app name (-n) without the credentials. For instance:

D:\Program Files\Microsoft Firewall Client>credtool -r -n dns
Read credentials for [dns]
User: [UserName]
Domain: [DomainName]
Password: [**********]

..reveals the UserName and Domain used by the dns service. Notice that the password is hidden to prevent improper use.

That’s all for today. As usual, feel free to contact me.