Computers that go through the ISA firewall to access resources outside their networks fall into one or more ISA 2004 client type categories. These are:
The SecureNAT client
The Web Proxy client
A single machine can be configured to act as multiple ISA 2004 client-types. For example, a Windows XP computer can be configured as a SecureNAT, Firewall and Web Proxy client. Another Windows XP computer can be configured as only a Firewall and Web Proxy client. A Linux machine can be configured as a SecureNAT client and Web Proxy client.
Table 5.1 provides an overview of the ISA 2004 client types, how each is installed or configured, which operating systems each supports, protocols supported by each, type of user-level authentication each supports, and special deployment considerations for each type.
|
Feature
|
SecureNAT client
|
Firewall client
|
Web Proxy client
|
|---|---|---|---|
|
Installation of client software required?
|
No. SecureNAT clients require only a default gateway address that can route Internet-bound requests through the ISA 2004 firewall. The default gateway is set in the TCP/IP properties for the computer's network adapter.
|
Yes. The Firewall client software must be installed from an installation share on the network. The Firewall client installation share can be on the ISA 2004 firewall itself, or (preferably) on a File Server located
|
No. However, Web browsers on client computers must be configured to use the ISA 2004 firewall as their Web Proxy. The proxy is set in the Web browser's connection settings.
|
|
Operating system support
|
SecureNAT clients support all operating systems. The SecureNAT client type can be used with Windows, MacOS, Unix, Linux, and configany other operating system that supports TCP/IP networking.
|
The Firewall client supports all post-Windows 95 platforms, from Windows 98 to Windows Server 2003.
|
The Web ProxyProxy client supports all platforms, but does so by way of a Web application. All Web browsers that can be ured to use a proxy server can function as Web ProxyProxy clients.
|
|
Protocol support
|
All simple protocols are supported by SecureNAT. Complex protocols (those requiring multiple connections) require an nonapplication filter be installed on the ISA Server 2004 firewall.
|
The Firewall client supports all Winsock applications that use the TCP and UDP protocols; the Firewall client does not mediate TCP/UDP connections.
|
The Web ProxyProxy client supports HTTP, HTTPS (SSL), and HTTP tunneled FTP (Web proxied FTP)
|
|
User-level authentication supported?
|
No. SecureNAT clients cannot authenticate with the ISA 2004 firewall unless the client applications support SOCKS 5 and a SOCKS 5 application filteris installed on the firewall.
|
Yes. The Firewall client enables strong user/group- based access control by trans- parently forwarding client credentials to the ISA 2004 firewall.
|
Yes. Web Proxy clients will authenticate with the ISA firewall requests credentials. No credentials are sent if an anonymous access rule enabling the connection is available to the Web Proxy client.
|
|
Deployment Considerations
|
All non-Windows operating consystems can be configured as SecureNAT clients if they require protocol access outside of HTTP/HTTPS and FTP. All post-Windows 95 Windows operating systems configushould be configured as Firewall clients if at all possible. All servers published transvia Server Publishing Rules funcshould be configured as SecureNAT clients. Use SecureNAT on Windows clients (except for published servers) only when outbound ICMP or PPTP is required.
|
All Windows operating systems supporting Firewall client installation (post- Windows 95) should have the Firewall client installed unless there are technical or management barriers that prevent this. The Firewall client increases the overall level of security and accessibility for all machines with the Firewall client software installed.
|
All browsers should be figured as Web Proxy clients when authentication is required for Web (HTTP/HTTPS/FTP) access. If user authentication is not required, Web Proxy ration is not required because the ISA 2004 firewall will provide parent Web ProxyProxy tionality for Firewall and SecureNAT clients.
|
A SecureNAT client is any device configured with a default gateway address that can route Internet-bound connections through the ISA 2004 firewall. That is, the ISA firewall's role is closely related to the role of a router for outbound access. The SecureNAT client does not have a traditional client/server relationship with the ISA Server. There are three network scenarios in which the SecureNAT client is most commonly found:
Simple
VPN client
A 'simple network scenario' is one that has only a single subnet located behind the ISA 2004 firewall computer. For example, you have an ISA 2004 firewall sitting at the edge of the network with an interface directly connected to the Internet and a second interface connected to the Internal network. All the machines behind the ISA 2004 firewall are on a single subnet (for example, 10.0.0.0/8). There are no routers on the Internal network. Figure 5.1 depicts a typical simple network scenario.
Figure 5.1: SecureNAT Simple Network Scenario
In the simple network scenario, the default gateway of the SecureNAT client is configured as the IP address of the Internal interface of the ISA 2004 firewall. You can manually configure the default gateway address, or you can use DHCP to automatically assign addresses to the SecureNAT clients. The DHCP server can be on the ISA 2004 firewall itself, or it can be located on a separate machine on the Internal network.
In the 'complex network scenario,' the Internal network consists of multiple network IDs that are managed by a router or series of routers or layer 3 switch(s). In the case of the complex network, the default gateway address assigned to each SecureNAT client depends on the location of the SecureNAT client computer. The gateway address for the SecureNAT client will be a router that allows the SecureNAT client access to other networks within the organization, as well as the Internet. The routing infrastructure must be configured to support the SecureNAT client so that Internet-bound requests are forwarded to the Internal interface of the ISA 2004 firewall. Figure 5.2 depicts the SecureNAT complex network scenario.
Figure 5.2: SecureNAT Complex Network Scenario
The 'VPN client scenario' applies to machines that have created a VPN connection with the ISA 2004 firewall.
With ISA Server 2000, when a VPN client computer establishes a connection with the VPN server, the VPN client's routing table is changed so that the default gateway is an address on the VPN server. Unless changes are made to the default client configuration, the client will not be able to connect to resources on the Internet while connected to the ISA Server 2000 VPN server.
It was possible to configure the ISA Server 2000 VPN client as a Firewall or Web Proxy client and allow the VPN client access to the Internet through the ISA Server 2000 firewall. Alternatively, the ISA Server 2000 VPN client could be configured to allow split tunneling.
In contrast to ISA Server 2000, the ISA 2004 VPN server does not require you to configure the VPN clients to be Firewall or Web Proxy clients in order to access the Internet through the same ISA 2004 VPN server to which they connect. Because the VPN clients are not configured as Web Proxy or Firewall clients, they are de facto SecureNAT clients. This allows VPN users to access the corporate network via the VPN connection, while at the same time allowing them to access the Internet via their connection to the ISA firewall, and removes the risks inherent in split tunneling.
364
365
Note that you do not need to have a deep understanding of VPN client routing table configuration or how different versions of the Windows VPN client handle default route assignments. Just remember that when a VPN client creates a VPN connection with the ISA 2004 firewall/VPN server, that client will be able to connect to the Internet via the ISA 2004 firewall based on access rules that you configure.
| Warning! |
Split tunneling represents a significant security risk and should never be enabled on your VPN clients. ISA 2004 supports VPN client SecureNAT connections to the Internet through the same ISA 2004 firewall to which they connect, and thus, obviates the need for split tunneling. In addition, the ISA 2004 firewall enhances the SecureNAT client support for VPN clients by enabling user/group-based access controls for VPN clients. We will discuss the issue of split tunneling and the risks it imposes, in addition to the enhanced SecureNAT client support for VPN clients, in detail in Chapter 8 Remote Access and Site-to-Site Virtual Private Networking.
|
While SecureNAT clients are the simplest ISA 2004 client types to configure, they are also the least capable and the least secure of the three ISA 2004 client types. Limitations of the SecureNAT client include:
Inability to authenticate with the firewall for strong user/group-based access control
Inability to take advantage of complex protocols without the aid of an application filter
Dependency on the routing infrastructure to access the Internet
Requirement for a Protocol Definition to be configured on the ISA 2004 firewall to support connections made through the ISA 2004 firewall
SecureNAT clients do not send credentials to the ISA 2004 firewall because, in order for credentials to be sent to the firewall, there must be a client software component configured to send them. The basic TCP/IP protocol stack does not provide for user authentication and requires an application component to send user credentials.
The Firewall and Web Proxy clients can send user credentials, but the SecureNAT client cannot. The Firewall client uses the Firewall client software to send user credentials, and Web browsers configured to use the ISA 2004 firewall as a Web Proxy have the built-in capability to send user credentials. You cannot use strong user/group-based outbound access controls for machines configured only as SecureNAT clients.
SecureNAT clients cannot connect to the Internet (or any other location through the ISA 2004 firewall) using complex protocols without the aid of an application filter installed on the ISA firewall. A complex protocol is one that requires multiple primary or secondary connections. A classic case of a complex protocol would be FTP standard (Port) mode connections.
When the standard or port mode FTP client establishes a connection to the FTP server, the initial connection (the 'control channel') is established on TCP port 21. The FTP client and server then negotiate a port number on which the FTP client can receive the data (the file to download), and the FTP server returns the data from its own TCP port 20 to the negotiated port. This inbound connection is a new primary connection request and not represent a response to the primary outbound connection made by the FTP client when it established the control channel session.
The firewall must be aware of the communications going on between the FTP standard mode client and the FTP server so that the correct ports are available for the new inbound connection request to the ISA 2004 firewall. This is accomplished on ISA 2004 via its intelligent FTP Access Application Filter. Figure 5.3 depicts the FTP standard mode client and server communications.
Figure 5.3: FTP Standard Mode Client/Server Communications
This SecureNAT limitation regarding complex protocols is especially problematic when it comes to Internet games and voice/video applications. These applications typically require multiple inbound and outbound primary connections. The SecureNAT client will not be able to use these applications unless there are specific application filters on the firewall to support them. In contrast, the Firewall client is easily able to handle applications requiring multiple inbound and outbound primary connections without installing anything extra on the firewall.
Of course, there's an exception to every rule, and here's the exception to the statement above: Complex protocol support for SecureNAT clients is possible if the application installed on the SecureNAT client is designed to work with a SOCKS proxy. In this case, the application is explicitly configured to communicate with the ISA 2004 firewall's SOCKS 4 application filter. The SOCKS 4 application filter can manage the connections on behalf of the SecureNAT client machine's application.
| Warning! |
Although SecureNAT clients running SOCKS 4 applications might be able to support complex protocols for the application configured to use the SOCKS proxy, the SOCKS proxy will not enable the client to benefit from user/group authentication. The SOCKS 4 proxy application filter on the ISA 2004 firewall does not accept user credentials that would enable user/group-based access control. However, if you require user authentication for SOCKS clients, you might want to consider COrnerpost Software's Surrogate Socket 5.0 application (http://www.cornerpostsw.com/surrogatesocket50/surrogatesocket50.asp).
|
The SecureNAT client is dependent on the organization's routing infrastructure. Unlike the Firewall and Web Proxy clients, which send their Internet connection requests directly to the ISA 2004 firewall (and thus, only need to know the route to the Internal interface of the ISA 2004 firewall machine), the SecureNAT client depends on the routing infrastructure to forward Internet-bound requests to the Internal interface of the ISA 2004 firewall. If the connection encounters a router in the path that does not route Internet-bound connections through the ISA 2004 firewall, the connection attempt will fail.
| Tip |
There must be a protocol definition created on the ISA 2004 firewall for each protocol you want the SecureNAT client to access. This is true even when you configure an Access Rule that allows the SecureNAT client access to all protocols. For the SecureNAT client, 'all protocols' means all protocols for which there is a Protocol Definition. This is in contrast to the Firewall client, where an Access Rule specifying all protocols means all TCP and UDP protocols, regardless of whether or not there is a Protocol Definition for a particular protocol.
|
Because of the limitations of SecureNAT, a computer should only be configured as a SecureNAT client when at least one of the following conditions exists:
The machine does not support Firewall client software (non-Windows clients) and requires protocol support outside of what the Web Proxy client can provide (protocols other than HTTP/HTTPS and FTP upload).
The machine requires outbound access to the ICMP and PPTP.
For administrative or political reasons, you cannot install the Firewall client on machines requiring protocol access outside of that provided by the Web Proxy client configuration.
Disadvantages of the SecureNAT configuration are summarized in Table 5.2.
|
Disadvantage
|
Implication
|
|---|---|
|
Inability to authenticate with the ISA 2004 firewall
|
The SecureNAT client is unable to send user credentials (user name and password) to the ISA 2004 firewall. This prevents the use of strong user/group-based outbound access control over Internet access. The only outbound access control available for SecureNAT clients is based on a client source IP address.
|
|
Inability to use complex protocols
|
Complex protocols require multiple primary and/or secondary connections. Internet games, voice/video applications, and instant messaging applications often require complex protocol support. The SecureNAT client cannot access Internet applications using complex protocols without the assistance of an application filter installed on the ISA 2004 firewall machine. The only exception to this is when the application installed on the SecureNAT client is configured to support SOCKS proxies. The ISA 2004 firewall includes a built-in SOCKS 4 filter.
|
|
Dependency on the existing network routing infrastructure
|
The SecureNAT client does not forward connections directly to the ISA 2004 firewall. Instead, it depends on the organization's routing infrastructure. Each router along the path from the SecureNAT client to the ISA 2004 firewall must be aware that the path to the Internet is through the ISA 2004 firewall. This may require reconfiguring network routers with new gateways of last resort (default gateways).
|
|
User information is not included in the Firewall and Web Proxy logs
|
The user name is only included in Firewall and Web Proxy logs when a client sends that information to the ISA firewall. A client piece is always required to send user information to the firewall since there are no provisions in the layer 1 through 6 headers to provide this information. Only the Firewall client and Web Proxy client con- figurations can send user information to the ISA firewall and have this information included in the log files. SecureNAT client connections allow for logging of the source IP address, but user information is never recorded for machines configured as only SecureNAT clients.
|
Despite the limitations discussed in the foregoing section, you should not conclude that the SecureNAT client is all bad. In fact, some of the SecureNAT client's weaknesses also represent the SecureNAT client's strengths. Advantages of the SecureNAT client configuration include:
Support for non-Windows client operating systems
Support for non-TCP/UDP protocols (for example PPTP[GRE] and ICMP)
No requirement for client software installation or configuration
The primary purpose of the SecureNAT client configuration is to enable non-Microsoft operating systems access to a broader range of protocols than is supported by the Web Proxy client configuration. The Firewall client works only with Windows operating systems. Without the SecureNAT client configuration, the only protocols that would be available to non-Microsoft operating systems are those provided by the Web Proxy client configuration (HTTP/HTTPS and FTP download).
The SecureNAT client has an important use for Microsoft operating systems, as well. The Firewall client software intercepts outbound TCP and UDP connections established by Winsock applications and forwards them to the ISA 2004 firewall. However, the Firewall client software does not intercept non-TCP/UDP communications. Networking protocols such as ICMP and GRE (used in the PPTP VPN protocol) do not use UDP or TCP as a transport protocol, and thus, are not evaluated by the Firewall client. You must configure client computers as SecureNAT clients to support outbound access through the ISA 2004 firewall using these protocols.
One significant downside of this situation is that you cannot use user/group-based access controls over which hosts can create outbound connections using non-TCP/UDP protocols. For example, you might want to allow outbound PPTP VPN connections for a specific group of users. This is not possible because PPTP requires GRE; this bypasses the Firewall client software, and therefore, no user information is passed to the ISA 2004 firewall. If you create an outbound PPTP Access Rule that requires user authentication, the connection attempt will fail. The only method available to control an outbound PPTP connection is by source IP address. We will cover this subject in more detail in Chapter 8.
| Note |
ICMP is most commonly used by the ping utility, although other utilities such as tracert also use ICMP. GRE is required if you wish to allow clients outbound access to external VPN servers using the PPTP VPN protocols. In contrast, outbound VPN clients that use the L2TP/IPSec NAT Traversal (NAT-T) protocol do not have to be configured as SecureNAT clients. L2TP/IPSec NAT-T uses only UDP ports 500 and 4500 for outbound access to L2TP/IPSec NAT-T VPN servers. Because of this, you can use the Firewall client configuration to force strong user/group-based access controls over L2TP/IPSec VPN connections.
|
Probably the most common reason for implementing the SecureNAT client configuration is to avoid installing or configuring client software. Firewall and network administrators are loath to install software on client computers that imposes itself on the network stack. In addition, there is a perception that significant administrative overhead is involved with installing the ISA 2004 Firewall client and configuring the Web Proxy client, although in reality, there is not.
In fact, there is an extremely low likelihood that the Firewall client software will interfere with networking components of any client software, and the administrative overhead is very small when you automate the Firewall client and Web Proxy client installation and configuration.
We will discuss how to automate client installation and configuration later in this chapter. Table 5.3 details the advantages of the SecureNAT client configuration.
|
Advantage
|
Implication
|
|---|---|
|
Provides additional protocol support for non-Windows operating systems
|
Non-Windows operating systems do not support the Firewall client software. If you wish to provide support for protocols other than those allowed via the Web Proxy client configuration (that is, HTTP/HTTPS/FTP download), the SecureNAT configuration is your only option for non-Windows operating system clients such as Linux, UNIX, and Macintosh.
|
|
Support for non- TCP/UDP Protocols
|
The SecureNAT client is the only ISA 2004 client configuration that supports non-TCP/UDP protocols. Ping, tracert, and PPTP are some of the non-TCP/UDP protocols that require the SecureNAT client configuration. Note that you cannot exert strong user/ groupbased access controls for non-TCP/UDP protocols because the SecureNAT client configuration does not support user authentication.
|
|
Does not require client software installation or configuration
|
The SecureNAT client does not require any specific software be installed or configured on the client computers. The only requirement is that the default gateway address on the client machine be configured so that Internet-bound requests are forwarded through the ISA 2004 firewall.
|
|
Best configuration - for published servers
|
When publishing a server to the Internet, the server often needs to not only accept connections from Internet-based hosts, but also needs to initiate new connections. The best example is an SMTP relay configured for both inbound and outbound relay. The SMTP relay does not need to be configured as a SecureNAT client to receive inbound connections from remote SMTP servers (because you have the option to replace the original source IP address of the Internet host with the IP address of the ISA 2004 firewall). However, the SMTP relay does need to be configured as a SecureNAT client to send outbound mail to Internet SMTP servers. We will cover this issue in more detail in Chapter 10.
|
As we discussed earlier in the context of network services support, name resolution is a critical issue not only when installing the ISA 2004 firewall software on the server, but for all types of ISA 2004 clients. Each ISA 2004 client resolves names in its own way. The SecureNAT client resolves names for hosts on the Internal and External networks using the DNS server address configured on the SecureNAT client's own network interfaces.
The fact that the SecureNAT client must be able to resolve names based on its own TCP/IP configuration can pose challenges for Internet-connected organizations that require access to resources both while connected to the corporate network and when those same hosts must leave the Internal network and connect to corporate resources from remote locations. In addition, there are significant challenges when SecureNAT clients attempt to 'loop back' through the ISA 2004 firewall to access resources on the Internal or other protected networks.
SecureNAT clients must be configured to use a DNS server that can resolve both Internal network names and Internet host names. Most organizations host their own DNS servers within the confines of the corporate network. In this case, the SecureNAT client should be configured to use the Internal DNS server that can resolve Internal and Internet host names.
372
Consider the example of an organization that uses the domain name internal.net for resources located on the Internal network behind the ISA 2004 firewall. The organization uses the same domain name to host resources for remote users and publishes those resources on the Internal network. For example, the company hosts its own Web server on the Internal network, and the IP address of that Web server on the Internal network is 192.168.1.10.
The organization also hosts its own public DNS servers and has entered the IP address 222.222.222.1 into the DNS database for the host name www.internal.net. External users use this name, www.internal.net, to access the company's Web server. The Web server is published using ISA 2004 Web Publishing Rules and external users have no problem accessing the published Web server.
Problems arise when SecureNAT clients on the Internal network try to reach the same Web server; the connection attempts always fail. The reason for this is that the SecureNAT clients are configured to use the same DNS server that is used by the external clients to resolve the name www.internal.net. This name resolves to the public address on the external interface of the ISA 2004 firewall that is used in the Web Publishing Rule. The SecureNAT client resolves the name www.internal.net to this address and forwards the connection to the external interface of the ISA 2004 firewall. The ISA 2004 firewall then forwards the request to the Web server on the Internal network.
The Web server then responds directly to the SecureNAT client computer. The reason for this is that the source IP address in the request forwarded by the ISA 2004 firewall to the Web Server on the Internal network is the IP address of the SecureNAT client. This causes the Web server on the Internal network to recognize the IP address as one on its local network and respond directly to the SecureNAT client. The SecureNAT client computer drops the response from the Web server because it sent the request to the public IP address of the ISA 2004 firewall, not to the IP address of the Web server on the Internal network. The response is dropped because the SecureNAT client sees this as a response to a connection it did not request. Figure 5.4 depicts the SecureNAT client looping back through the ISA 2004 firewall.
Figure 5.4: SecureNAT 'Loop Back'
The solution to this problem is the split DNS infrastructure. In almost all cases in which the organization requires remote access to resources located on the Internal network, the split DNS infrastructure provides the solution to name resolution problems for SecureNAT and roaming clients (hosts that move between the Internal network and locations outside the corporate network).
In a split DNS infrastructure, the SecureNAT client is configured to use an Internal DNS server that resolves names for resources based on the resource's Internal network address. Remote hosts can resolve the same names, but the external hosts resolve the same names to the IP address on the external interface of the ISA 2004 firewall that publishes the resource. This prevents the SecureNAT client from looping back through the ISA 2004 firewall, and connection attempts to published servers succeed for the SecureNAT clients. Figure 5.5 demonstrates how the split DNS infrastructure solves the 'looping back' issue for SecureNAT clients. Table 5.4 summarizes important DNS considerations for SecureNAT clients.
Figure 5.5: A Split DNS Solves the SecureNAT Paradox
| Note |
For this reason, Web developers should never 'hard code' IP addresses or names in links returned to Web users. For example, a Web developer might code a link that points to http://192.168.1.1/info into a Web page response to a user. Internal network clients can access this link because the IP address is that of the Web server on the Internal network, but remote access users will not be able to connect to this resource because the address is not accessible from the Internet. Many Java applications suffer from this type of poor coding, and even some Microsoft applications, such as SharePoint Portal Server (although some of these problems can be solved using the ISA 2004 firewall's Link Translator feature).
|
The Firewall client software is an optional client piece that can be installed on any supported Windows operating system to provide enhanced security and accessibility. The Firewall client software provides the following enhancements to Windows clients:
Allows strong user/group-based authentication for all Winsock applications using the TCP and UDP protocols
Allows user and application information to be recorded in the ISA 2004 firewall's log files
Provides enhanced support for network applications, including complex protocols that require secondary connections
Provides 'proxy' DNS support for Firewall client machines
Allows you to publish servers requiring complex protocols without the aid of an application filter
The network routing infrastructure is transparent to the Firewall client
The Firewall client software transparently sends user information to the ISA 2004 firewall. This allows you to create Access Rules that apply to users and groups and allow or deny access to any protocol, site, or content, based on a user account or group membership. This strong user/group-based outbound access control is extremely important. Not all users require the same level of access, and users should only be allowed access to protocols, sites, and content they require to do their jobs.
| Note |
The concept of allowing users access to only the protocols, sites, and content they require is based on the principle of least privilege. The principle of least privilege applies to both inbound and outbound access. For inbound access scenarios, Server and Web Publishing rules allow traffic from external hosts to Internal network resources in a highly controlled and monitored fashion. The same should be true for outbound access. In traditional network environments, inbound access is highly limited while users are allowed outbound access to virtually any resource they desire. This weak approach to outbound access control can put not only the corporate network at risk, but other networks as well, as Internet worms can easily traverse firewalls that do not restrict outbound access.
|
The Firewall client automatically sends user credentials (user name and password) to the ISA 2004 firewall. The user must be logged on with a user account that is either in the Windows Active Directory or NT domain, or the user account must be mirrored on the ISA 2004 firewall. For example, if you have an Active Directory domain, users should log on to the domain, and the ISA 2004 firewall must be a member of the domain. The ISA 2004 firewall is able to authenticate the user and allows or denies access based on the user's domain credentials.
If you do not have a Windows domain, you can still use the Firewall client software to control outbound access based on user/group. In this case, you must mirror the accounts that users log on to on their workstations to user accounts stored in the local Security Account Manager (SAM) on the ISA 2004 firewall computer.
For example, a small business does not use the Active Directory, but they do want strong outbound access control based on user/group membership. Users log on to their machine with local user accounts. You can enter the same user names and passwords on the ISA 2004 firewall, and the ISA 2004 firewall will be able to authenticate the users based on the same account information used when logging on to their local machines.
Windows 9x clients can be configured to forward domain credentials if they have the Active Directory client software installed. You can obtain the client software and installation instructions at http://support.microsoft.com/default.aspx?kbid=288358
A major benefit of using the Firewall client is that when the user name is sent to the ISA 2004 firewall, that user name is included in the ISA 2004 firewall's log files. This allows you to easily query the log files for usernames and obtain precise information on that user's Internet activity.
In this context, the Firewall client provides not only a high level of security by allowing you to control outbound access based on user/group accounts, but also provides a high level of accountability. Users will be less enthusiastic about sharing their account information with other users when they know that their Internet activity is being tracked based on their account name, and they are held responsible for that activity.
Unlike the SecureNAT client, which requires an application filter to support complex protocols requiring secondary connections, the Firewall client can support virtually any Winsock application using TCP or UDP protocols, regardless of the number of primary or secondary connections, without requiring an application filter.
The ISA 2004 firewall makes it easy for you to configure Protocol Definitions reflecting multiple primary or secondary connections and then create Access Rules based on these Protocol Definitions. This provides a significant advantage in terms of Total Cost of Ownership (TCO) because you do not need to purchase applications that are SOCKS proxy aware, and you do not need to incur the time and cost overhead involved with creating customer application filters to support 'off-label' Internet applications.
In contrast to the SecureNAT client, the Firewall client does not need to be configured with a DNS server that can resolve Internet host names. The ISA 2004 firewall can perform a 'proxy' DNS function for Firewall clients.
For example, when a Firewall client sends a connection request for ftp://ftp.microsoft.com, the request is sent directly to the ISA 2004 firewall. The ISA 2004 firewall resolves the name for the Firewall client based on the DNS settings on the ISA 2004 firewall's network interface cards. The ISA 2004 firewall returns the IP address to the Firewall client machine, and the Firewall client machine sends the FTP request to the IP address for the ftp.microsoft.com FTP site. The ISA 2004 firewall also caches the results of the DNS queries it makes for Firewall clients. Unlike ISA Server 2000, which cached this information for a default period of 6 hours, the ISA 2004 firewall caches the entries for a period determined by the TTL on the DNS record. This speeds up name resolution for subsequent Firewall client connections to the same sites. Figure 5.6 shows the name resolution sequence for the Firewall client.
Figure 5.6: Firewall Name Resolution Sequence
The Firewall client sends a request for ftp.microsoft.com.
The ISA 2004 firewall sends a DNS query to an Internal DNS server.
The DNS server resolves the name ftp.microsoft.com to its IP address and returns the result to the ISA 2004 firewall.
The ISA 2004 firewall returns the IP address of ftp.microsoft.com to the Firewall client that made the request.
The Firewall client sends a request to the IP address for ftp.microsoft.com and the connection is complete.
The Internet server returns requested information to the Firewall client via the Firewall client connection made to the ISA 2004 firewall.
The final major benefit conferred by the Firewall client is that the routing infrastructure is virtually transparent to the Firewall client machine. In contrast to the SecureNAT client, which depends on its default gateway and the default gateway settings on routers throughout the corporate network, the Firewall client machine only needs to know the route to the IP address on the Internal interface of the ISA 2004 firewall.
The Firewall client machine 'remotes' or sends requests directly to the IP address of the ISA 2004 firewall. Since corporate routers are typically aware of all routes on the corporate network, there is no need to make changes to the routing infrastructure to support Firewall client connections to the Internet. Figure 5.7 depicts the 'remoting' of these connections directly to the ISA 2004 firewall computer. Table 5.5 summarizes the advantages of the Firewall client application.
Figure 5.7: Firewall Client Connections to the ISA 2004 Firewall are Independent of the Default Gateway Configurations on Interposed Routers
|
Firewall Client Advantage
|
Implication
|
|---|---|
|
Strong user/group based authentication for Winsock TCP and UDP protocols
|
Strong user/group based authentication for Winsock applications using TCP and UDP allows you fine-tuned granular control over outbound access and makes it possible for you to implement the principle of least privilege, which protects not only your own network, but other corporations' networks as well.
|
|
User name and application information is saved in the ISA 2004 firewall's logs
|
While strong user/group-based access controls increase the security the firewall provides for your network, user name and application name information saved in the ISA 2004 firewall's logs increases accountability and enables you to easily research what sites, protocols, and applications any user running the Firewall client software has accessed.
|
|
Enhanced support for network applications and protocols
|
The Firewall client can access virtually any TCP or UDP-based protocol, even those used by complex protocols that require multiple primary and/or secondary connections. In contrast, the SecureNAT client requires an application filter on the ISA 2004 firewall to support complex protocols. The overall effect is that the Firewall client reduces the TCO of the ISA 2004 firewall solution.
|
|
Proxy DNS support for Firewall clients
|
The ISA 2004 firewall can resolve names on behalf of Firewall clients. This offloads the Internet host name resolution responsibility from the Firewall client computer and allows the ISA 2004 firewall to keep a DNS cache of recent name resolution requests. This DNS proxy feature also enhances the security con- figuration for Firewall clients because it eliminates the requirement that the Firewall client be configured to use a public DNS server to resolve Internet host names.
|
|
Enables publishing servers that require a complex networking protocol
|
Web and Server Publishing Rules support simple protocols, with the exception of those that have an application installed on the ISA 2004 firewall, such as the FTP Access application filter.You can install Firewall client software on a published server to support complex protocols, such as those that might be required if you wished to run a game server on your network. It is important to note the Microsoft no longer officially supports this configuration and they recommend that you have a C++ programmer code an application filter to support your application.
|
|
The network routing infrastructure is virtually transparent to the firewall client
|
Unlike the SecureNAT client, which relies on the organization's routing infrastructure to use the ISA 2004 firewall as its Internet access firewall, the Firewall client only needs to know the route to the IP address on the Internal interface of the ISA 2004 firewall. This significantly reduces the administrative overhead required to support the Firewall client versus the SecureNAT client.
|
The details of how the Firewall client software actually works are not fully documented in the Microsoft literature. In fact, if you do a network trace of Firewall client communications using the Microsoft Network Monitor, you'll see that the Network Monitoring is unable to decode the Firewall client communications. However, Ethereal does have a rudimentary Firewall client filter you can use (www.ethereal.com).
What we do know is that the ISA 2004 Firewall client, unlike previous versions, uses only TCP 1745 for the Firewall client Control Channel. Over this control channel, the Firewall client communicates directly with the ISA 2004 firewall service to perform name resolution and network application-specific commands (such as those used by FTP and Telnet). The firewall service uses the information gained through the control channel and sets up a connection between the Firewall client and the destination server on the Internet. The ISA firewall proxies the connection between the Firewall client and the destination server.
| Note |
The Firewall client only establishes a control channel connection when connecting to resources not located on the Internal network.
|
In ISA Server 2000, the Internal network was defined by the Local Address Table (LAT). The ISA 2004 firewall does not use a LAT because of its enhanced multinetworking capabilities. Nevertheless, the Firewall client must have some mechanism in place to determine which communications should be sent to the firewall service on the ISA 2004 firewall and which should be sent directly to the destination host with which the Firewall client wants to communicate.
The Firewall client solves this problem using addresses defined by the Internal Network. The internal network for any specific Firewall client consists of all the addresses reachable from the network interface that is connected to the Firewall client's own network. This situation gets interesting on a multihomed ISA 2004 firewall that has multiple internal networks associated with different network adapters. In general, all hosts located behind the same network adapter (regardless of network ID) are considered part of the same internal network and all communications between hosts on the same internal network should bypass the Firewall client.
Addresses for the Internal network are defined during installation of the ISA 2004 firewall software, but you can create other 'Internal' networks as required.
| ISA 2004 Security Alert |
You may have multiple interfaces on the same ISA 2004 firewall computer. However, only a single network may have the name Internal. The Internal network consists of a group of machines that have an implicit trust in each other (at least enough trust to not require a network firewall to control communications between them). You can have multiple internal networks, but additional internal networks cannot be included in the Internal address range of another Internal network. This means you cannot use the centrally-configured network address range configured for the Internal network and additional Internal networks to bypass the Firewall client when communicating between Internal networks connected to the ISA 2004 firewall via different network interfaces. However, the centralized configuration of the Firewall client can be done per network, so you can control the Firewall client settings on a per network basis. This allows you a measure of control over how the Firewall client configuration settings are managed on each network. However, this solution does not help in the network within a network scenario, where there are multiple network IDs located behind the same network interface card. In the network within the network scenario, you can use a Local LAT (locallat.txt) file to override the centralized Internal network settings. For more information on the ISA 2004 firewall's concept of the Internal network, please see Chapter 4.
|
The most significant improvement the ISA 2004 Firewall client has over previous versions of the Firewall client (Winsock Proxy Client 2.0 and ISA Server 2000) is that you now have the option to use an encrypted channel between the Firewall client and the ISA 2004 firewall.
Remember, the Firewall client sends user credentials transparently to the ISA 2004 firewall. The ISA 2004 Firewall client encrypts the channel so that user credentials will not be intercepted by someone who may be 'sniffing' the network with a network analyzer (such as Microsoft Network Monitor or Ethereal). Note that you do have the option of configuring the ISA 2004 firewall to allow both secure encrypted and non-encrypted control channel communications.
For a very thorough empirical study on how the Firewall client application works with the firewall service in ISA Server 2000, check out Stefaan Pouseele's article Understanding the Firewall Client Control Channel at: www.isaserver.org/articles/Understanding_the_Firewall_Client_Control_Channel l.
| Note |
If Internet Protocol security (IPSec) transport mode is enabled for a network so that the Firewall client machine uses IPSec transport mode to connect to the ISA 2004 firewall, you may experience unusual and unpredictable connectivity issues. If Firewall clients in the network do not behave as expected, disable IP routing at the ISA 2004 firewall console. In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server, and then expand the Configuration node; click the General node. In the details pane, click Define IP Preferences. On the IP Routing tab, verify that the Enable IP Routing check box is not selected. Note that disabling IP Routing can significantly degrade the performance of your SecureNAT clients
|
The Firewall client share contains the installation files for the Firewall client. Regardless of the method you use to distribute the Firewall client, you must install the Firewall client share on either the ISA 2004 firewall or a file server on the Internal network. We recommend that you do not install the Firewall client installation share on the ISA 2004 firewall.
When the Firewall client share is installed on the ISA 2004 firewall, a Firewall System Policy Rule (a type of Access Rule that is processed before using defined Access Rules) is created that allows a number of potentially risky protocols access to the firewall machine. These protocols include:
Microsoft Common Internet File System (CIFS) (TCP)
Microsoft CIFS (UDP)
NetBIOS Datagram
NetBIOS Name Service
NetBIOS Session
In addition, File and Printer Sharing must be enabled on the Internal interface. These Microsoft File and Printer sharing services and protocols, as well as the Client for Microsoft Networks service, can pose a significant risk to the ISA 2004 firewall and should be disabled, if at all possible, on all ISA 2004 network interfaces. You can disable these services and still make the Firewall client share available to network users by installing the Firewall client share on another machine on the corporate network.
Do the following to install the Firewall client share on a file server on the Internal network:
Place the ISA 2004 CD into the CD tray on the file server, and let the Autorun menu appear. Click Install ISA Server 2004.
Click Next on the Welcome to the Installation Wizard for Microsoft ISA 2004 page.
Select I accept the terms in the license agreement and click Next.
Enter your User Name, Organization and Product Serial Number in the text boxes provided. Click Next.
On the Setup Type page, select Custom and click Next.
Click the Firewall Services icon, and click This feature will not be available. Click the ISA Server Management icon, and click This feature will not be available. Click the Firewall Client Installation Share icon, and click This feature, and all subfeatures, will be installed on local hard drive (see Figure 5.8). Click Next.
Figure 5.8: Installing the Firewall Client Installation Files
Click Install on the Ready to Install the Program page.
Click Finish on the Installation Wizard Completed page.
Close the Autorun page.
The Firewall client installation share is installed in the default local path <Program Files>\ \Microsoft ISA Server\clients with a share name of mspclnt. The default Share Permissions on the folder is Everyone Read. The default NTFS permissions on the share are:
Administrators Full Control
Authenticated Users Read & Execute, List Folder Contents and Read
System Full Control
There are a number of methods you can use to install the Firewall client software. These include:
Using an SMB/CIFS connection to a share on a file server
Active Directory Group Policy Software Management
Silent Installation Script
Systems Management Server (SMS)
In this section, we will cover the manual installation of the Firewall client. Users who choose this method of installing the Firewall client software must be local administrators on the machine on which they install the software.
For example, if the machine is a laptop computer that is also a member of the corporate domain, make sure the user has a local account on the laptop that is a member of the Administrators group. Have the user log off the domain and log on to the local computer. The user can then connect to the Firewall client share on the network file server if the local user account has the same name and password as a domain account (assuming that the file server belongs to the domain). The user may need to enter network credentials when connecting to the File server if the laptop's local account the user is currently logged into is not mirrored on the file server or in the Active Directory (if the file server and the user are members of the same Active Directory domain).
All users of the computer have access to the Firewall client software after it is installed. That means the user can log off from the local account and log back in with domain credentials and still use the Firewall client software. Note that the Web Proxy settings are not applied to all user accounts, so subsequent users will need to use the Firewall client applications to automatically configure their browsers. We will cover that procedure later in this chapter.
If you do not allow your users to be members of the Administrators group on their local machines, you must use one of the automated approaches to install the Firewall client software before the user logs on. You can use Active Directory Group Policy Software Assignment or Systems Management Server (SMS) to accomplish this task.
Some things to take note of regarding installation of the Firewall client software:
Do not install the Firewall client software on the ISA 2004 firewall machine.
Do not install the Firewall client software on a domain controller or other network servers. The only exception to this rule is when you must publish a server that requires complex protocol support. For example, many game servers require multiple primary and secondary connections. In this case, the Firewall client must be installed on the published server
The Firewall client software begins working immediately after installation is complete. You do not need to restart the computer.
You can install the Firewall client on any version of Windows (except Windows 95) as long as Internet Explorer 5.0 is installed.
Perform the following steps to install the Firewall client software from a file share on the Internal network:
Click Start and then click Run.
In the Run dialog box, enter \\FILESERVER\mspclnt\setup (where FILESERVER is the name of the ISA 2004 firewall) and click OK.
Click Next on the Welcome to the Install Wizard for Microsoft Firewall Client page.
Click Next on the Destination Folder page.
On the ISA Server Computer Selection page, select Connect to this ISA Server computer, and enter isafirewall.msfirewall.org (where isafirewall.msfirewall.org is the name of the 2004 firewall) in the text box below it. Click Next.
Click Install on the Ready to Install the Program page.
Click Finish on the Install the Wizard Completed page.
You will see the Firewall client icon in the system tray (see Figure 5.9). If there is an active TCP or UDP connection to a network that is not the Internal network, the icon will have a GREEN up-pointing arrow.
Figure 5.9: Firewall Client Icon
| Tip |
VPN clients can install the Firewall client software while connected to the network using a VPN client connection.
|
There are two places where you can configure the Firewall client software: at the Microsoft Internet Security and Acceleration Server 2004 management console and at the Firewall client computer itself. Configuration changes made in the Microsoft Internet Security and Acceleration Server 2004 management console apply to all Firewall client computers, and those made at the client apply only to that individual client.
388
389
Centralized Firewall client configuration options are carried out in the Microsoft Internet Security and Acceleration Server 2004 management console. Firewall client configuration is done for each network configured to support Firewall client connections. Firewall client connections can be made from:
Perimeter Networks
Internal Networks
All other network types do not support Firewall client connections. When Firewall client connections are enabled for a network, incoming connections to the ISA 2004 firewall to TCP and UDP ports 1745 are enabled to the interface connected to that network.
You can reach the Firewall client configuration interface by opening the Microsoft Internet Security and Acceleration Server 2004 management console, expanding the server name and then expanding the Configuration node. In the Configuration node, click the Networks node, and then click the Networks tab in the Details pane. Right click on the Internal network and click Properties.
On the Firewall Client tab, put a checkmark in the Enable Firewall client support for this network check box, as shown in Figure 5.10. In the Firewall client configuration frame, enter the name of the ISA 2004 firewall computer in the ISA Server name or IP address text box.
Figure 5.10: The Internal Network Properties Dialog Box
The default setting is to use the computer (also known as the 'NetBIOS' name). However, you should replace the NetBIOS name with the fully-qualified domain name (FQDN) of the ISA 2004 firewall. When you replace the computer name with the FQDN, the Firewall client machines can use the DNS queries to correctly resolve the name of the ISA 2004 firewall. This will avoid one of the most common troubleshooting issues with Firewall client connectivity.
Make sure there is an entry for this name in your Internal network's DNS server. By default, all the interfaces on the ISA 2004 firewall will automatically register their names in the DNS, but if your DNS server does not support dynamic updates, you'll need to manually enter a Host (A) record for the ISA 2004 firewall.
We recommend that you disable automatic DNS registration for all interfaces on the ISA 2004 firewall. There reason for this is that you may want to enable Firewall client support for multiple internal or perimeter network interfaces on the ISA 2004 firewall. In this example, you would create a manual entry for each interface in the DNS. For example, the Internal network interface could be reached using the name isainternal.msfirewall.org and the perimeter network interface could be reached using the name isaperimeter.msfirewall.org. All you need to do is manually create Host (A) entries in your DNS to support this configuration.
| Note |
The most common problem ISA 2004 administrators encounter with the Firewall client is name resolution of the ISA 2004 firewall. If you do not have a DNS server on your network, use the IP address of the ISA 2004 firewall in the ISA Server name or IP address text box. Never use the default name that the software automatically enters into the text box; using the default name is a very common reason for Firewall client failures.
|
The Web Proxy client configuration settings are available in the Web browser configuration on the Firewall client computer frame. These settings will be automatically applied to the Web browser when the Firewall client is installed. Note that you can change the settings later and the Web browsers will automatically update themselves with the new settings.
The Automatically detect settings option allows the Web browser to automatically detect the Web Proxy service and configure itself based on the settings you configure on the Web Browser tab of the Internal Properties dialog box. Note that autodetection relies on Web Proxy AutoDiscovery (WPAD) entries being placed in DNS and/or DHCP.
The Use automatic configuration script option allows you to assign a proxy autoconfiguration file (PAC) address to the Web browser. The Web browser will then connect to the location you specify or use the default location; the default location is on the ISA 2004 firewall itself. Note that when you use the default location, you obtain the same information you would receive if you had configured the Web browser to use the Automatically detect settings option.
The Use default URL option automatically configures the browser to connect to the ISA 2004 firewall for autoconfiguration information. You can use the Use custom URL option if you want to create your own PAC file that overrides the settings on the automatically-generated file at the ISA 2004 firewall. You can find more information on PAC files and proxy client autoconfiguration files in Using Automatic Configuration and Automatic Proxy at www.microsoft.com/resources/documentation/ie/5/all/reskit/en-us/part5/ch21auto.mspx
The Use a Web Proxy server option allows you to configure the Web browser to use the ISA 2004 as its Web Proxy, but without the benefits of the autoconfiguration script. This setting provides higher Web browsing performance than the SecureNAT client configuration, but you do not benefit from the settings contained in the autoconfiguration script. The most important configuration settings in the autoconfiguration script include site names and addresses that should be used for Direct Access. For this reason, we recommend that you avoid this option unless you do not wish to use Direct Access to bypass the Web Proxy to access selected Web sites.
| Note |
Web Proxy client Direct Access configuration allows you to bypass the Web Proxy for selected Web sites. Some Web sites do not conform to Internet standards (Java sites are the most common offenders), and therefore, do not work properly through Web Proxy servers. You can configure these sites for Direct Access and the client machine will bypass the Web Proxy and use an alternate method (such as through the machine's SecureNAT or Firewall client configuration) to connect to the destination Web site. In order for the client to use an alternate method to connect, the client machine must be configured as a Firewall and/or SecureNAT client.
|
Click the Domains tab, as shown in Figure 5.11.
Figure 5.11: The Domains Tab
The Domains tab contains domains for which the Firewall client computer will not use the Firewall client software to establish a connection. The entries on the Domains tab have the same effect as adding machines in these domains to the Internal network (or whatever the network is named for which you are configuring Firewall client Properties). When a Firewall client makes a connection to a host that is located in one of the domains contained in the Domains tab, the Firewall client software is not used and the Firewall client machine attempts to connect directly to the destination host.
You can add domains by clicking the Add button, and enter the domain in the the Domain Properties dialog box, as shown in Figure 5.12.
Figure 5.12: The Domain Properties Dialog Box
Note that you can use wildcards when specifying a domain. If you want to specify a single computer, just enter the fully-qualified domain name (FQDN) of that host. If you want to include all hosts in a single domain, then use an asterisk (*) just to the left of the leftmost period in the FQDN. If you want to avoid using the Firewall client for all domains, then just enter an asterisk. If you choose this option, the Firewall client will never be used, and the client will depend on its Web Proxy or SecureNAT client settings to connect to hosts through the ISA 2004 firewall. Click OK after making your entry.
You should always include all Internal network domains in the Domains tab, as you usually want to allow direct connections to hosts located in the same domain. This prevents clients from 'looping back' throught the ISA 2004 firewall to access hosts located on the same network as the client making the request.
For example, if domain members are located on multiple subnets behind a single network interface representing a single network on the ISA 2004 firewall, you do not want hosts on the network to go through the ISA 2004 firewall to connect to hosts on the same network. This puts unneeded stress on the firewall, and the function of a network firewall is not to control these communications.
The ISA 2004 Firewall client uses a new and improved Remote Winsock Proxy Protocol that encrypts the communication channel between the Firewall client and the ISA 2004 firewall's Firewall service. This improves security because user credentials are transparently passed to the ISA 2004 firewall when the Firewall client makes an outbound connection request.
However, you have the option to allow non-encrypted Firewall client communications with the ISA 2004 firewall. This can provide you time to upgrade your existing Firewall client or Winsock Proxy 2.0 clients to the ISA 2004 Firewall client software.
Do the following to enable support for non-encrypted Firewall client connections from legacy Firewall/Winsock Proxy clients:
In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name, and then expand the Configuration node. Click on the General node.
On the General node, click the Define Firewall Client Settings link in the Details pane.
In the Firewall Client Settings dialog box, click the Connection node. Put a checkmark in the Allow non-encrypted Firewall client connections check box.
Click Apply, and then click OK.
Click Apply to save the changes and update the firewall policy.
Click OK in the Apply New Configuration dialog box.
If you have problems with Firewall client connections, make sure that the version of your Firewall client matches the encryption settings set on the ISA 2004 firewall. If you use legacy Firewall client software on your network, make sure that encryption is not enabled on the ISA 2004 firewall.
There are some configuration options available to users who have the Firewall client software installed. These options can be accessed by right-clicking on the Firewall client icon in the system tray and clicking the Configure command.
On the General tab (see Figure 5.13) of the Microsoft Firewall Client for ISA Server 2004, confirm that there is a checkmark in the Enable Microsoft Firewall Client for ISA 2004 check box.
Figure 5.13: The Firewall Client Configuration Dialog box
The Automatically detect ISA Server option takes advantage of a WPAD entry in a DHCP or DNS server to automatically detect the location of the ISA 2004 firewall, and then automatically obtain Firewall client configuration information from the ISA 2004 firewall.
Figure 5.14 illustrates the effect of clicking Detect Now button.
Figure 5.14: The Detecting ISA Server Dialog Box
After the Firewall client finds the ISA 2004 firewall, you will see the dialog box shown in Figure 5.15.
Figure 5.15: The Detecting ISA Server Dialog Box
It's important to remember that autodetection will only work if you have configured a WPAD entry in a DHCP or DNS server. We will go through detailed procedures on how to configure the WPAD entries later in this chapter.
You also have the option to Manually select ISA Server. This option allows you to enter the IP address or DNS name of the ISA 2004 firewall and then click the Test Server button to find the firewall. When you enter an IP address, the client sends a request to TCP port 1745 and obtains the autoconfiguration information directly from the ISA 2004 firewall. Included in the autoconfiguration information is the name of the ISA 2004 firewall, which is listed in the Detecting ISA Server dialog box.
The Network Monitor trace shown in Figure 5.16 shows that a connection is made by the Firewall client and some of the information return to the Firewall client is shown in the Hex decode pane.
Figure 5.16: Firewall Client Packet Traces
Click on the Web Browser tab. Here you have the option to Enable Web browser automatic configuration. This option pulls information from the Web browser configuration you set earlier in the Microsoft Internet Security and Acceleration Server 2004 management console. Users can click the Configure Now button, which makes it easy for users who inadvertently change the browser settings to get back to the ideal configuration with a click of a button. For this reason, you should not disable the Firewall client icon in the system tray.
| Tip |
You can disable the Firewall client icon in the system tray by putting a checkmark in the Hide icon in notification area when connected to ISA Server check box. You can automate this process by including an entry in the user's management.ini file, which is located in the \Documents and Settings\user_name\Local Settings\Application Data\Microsoft\Firewall Client 2004 folder. You should include the entry as follows: [TrayIcon] TrayIconVisualState=1 You can use a log-on script to place this file in the user's directory. More information on Firewall client configuration file settings are included in the next section.
|
The Firewall Client software adopts the centralized settings you configured by the ISA 2004 firewall. These settings determine things such as automatic Web Proxy client configuration, the ISA firewall's name, and ISA Server automatic detection and autoconfiguration. After the Firewall Client software is installed, ISA Server updates these client settings each time a client computer is restarted and every six hours after an initial refresh is made. The settings are also updated each time the user presses the Test Server button.
In addition to these settings, ISA firewall automatically updates the Firewall client with information about IP addresses that the client should consider local (the 'Internal' network for that particular Firewall client).
For almost all Winsock applications, the default Firewall client configuration works without any further configuration. However, there may be times when you want to modify the default settings. The Firewall client can be configured for each user on the Firewall client computer. The configuration is done by making changes to .ini files, which are installed on the Firewall client computer.
You can change the default settings for all components after installation. The new configuration settings take effect only when the client configuration is refreshed.
The configuration information is stored in a set of files, which are installed on the Firewall client computer. When the Firewall client is installed, the following files (also seen in Figure 5.17) are created on the Firewall client computer:
common.ini, which specifies the common configuration for all applications
management.ini, which specifies Firewall client management configuration settings
Figure 5.17: Firewall Client Configuration Files
These files are created for all users who log onto the computer and may be created for each specific user on the computer. Per-user settings override the general configuration settings applying to all users of the same Firewall client computer. These files are created in different locations, depending on the operating system. Unfortunately, we only have information on where these files are located on a Windows XP computer. You can use the Search function for your version of Windows to determine the location of the configuration files.
On Windows XP computers the files are located at:
\Documents and Settings\All Users\\Local Settings\Application Data\Microsoft\Firewall Client 2004 folder
\Documents and Settings\user_name\Local Settings\Application Data\Microsoft\Firewall Client 2004 folder
In addition to these files, the user may create another file called Application.ini, which specifies configuration information for specific applications.
There is an order of precedence regarding how the configuration .ini files are evaluated by the Firewall client. The order of evaluation is:
.ini files in the user's folder are evaluated first. Any configuration settings here are used by the Firewall client to determine how the Firewall client and applications that depend on the Firewall client will behave.
The Firewall client looks next in the Documents and Settings\All Users folder. Any additional configuration settings are applied. If a configuration setting specified contradicts the user-specific settings, it is ignored. The settings in the user's folder always take precedence.
The Firewall client detects the ISA Server computer to which it should connect and retrieves settings from the ISA 2004 firewall machine.
After retrieving the settings from the ISA 2004 firewall, the Firewall client examines the server-level settings. Any configuration settings specified on ISA Server are applied. If a configuration setting contradicts the user-specific or computer-specific settings, it is ignored.
The user on the Firewall client computer can create and modify the Firewall client configuration files and fine-tune the Firewall client behavior. The common.ini file, which is created when the Firewall client is installed, specifies the common configuration for all applications. The application.ini file controls configuration settings for applications on the client machine.
These files can be created for all users logged on to the computer and may be created for individual users on the computer. Individual user settings override settings that apply to all users of the computer. You can also use the Microsoft Internet Security and Acceleration Server 2004 management console to modify the Firewall client configuration settings.
Table 5.6 lists entries you can include when configuring the Firewall client application settings. The first column lists the keys that can be included in the configuration files. The second column describes the values to which the keys can be set.
Be aware that some settings can be configured only on the Firewall client computer and not via the Microsoft Internet Security and Acceleration Server 2004 management console.
|
Entry
|
Description
|
|---|---|
|
ServerName
|
Specifies the name of the ISA Server computer to which the Firewall client should connect.
|
|
Disable
|
Possible values: 0 or 1. When the value is set to 1, the Firewall client application is disabled for the specific client application.
|
|
DisableEx
|
Possible values: 0 or 1. When the value is set to 1, the Firewall client application is disabled for the specific client application. Applies only to the Firewall client for ISA 2004. When set, overrides the Disable setting.
|
|
Autodetection
|
(Can be set only on the Firewall client computer.) Possible values: 0 or 1. When the value is set to 1, the Firewall client application automatically finds the ISA Server computer to which it should
|
|
NameResolution
|
Possible values: L or R. By default, dotted decimal notation or Internet domain names are redirected to the ISA Server computer for name resolution and all other names are resolved on the local computer. When the value is set to R, all names are redirected to the ISA Server computer for resolution. When the value is set to L, all names are resolved on the local computer.
|
|
LocalBindTcpPorts
|
Specifies a Transmission Control Protocol (TCP) port, list, or range that is bound locally.
|
|
LocalBindUdpPorts
|
Specifies a User Datagram Protocol (UDP) port, list, or range that is bound locally.
|
|
RemoteBindTcpPorts
|
Specifies a TCP port, list, or range that is bound remotely.
|
|
RemoteBindUdpPorts
|
Specifies a UDP port, list, or range that is bound remotely.
|
|
ServerBindTcpPorts
|
Specifies a TCP port, list, or range for all ports that should accept more than one connection.
|
|
Persistent
|
Possible values: 0 or 1. When the value is set to 1, a specific server state can be maintained on the ISA Server computer if a service is stopped and restarted and if the server is not responding. The client sends a keep-alive message to the server periodically during an active session. If the server is not responding, the client tries to restore the state of the bound and listening sockets upon server restart.
|
|
ForceCredentials
|
(Can be set only on the Firewall Client computer.) Used when running a Windows service or server application as a Firewall Client application. When the value is set to 1, it forces the use of alternate user authentication credentials that are stored locally on the computer that is running the service. The user credentials are stored on the client computer using the Credtool.exe application that is provided with the Firewall Client software. User credentials must reference a user account that can be authenticated by ISA Server, either local to ISA Server or in a domain trusted by ISA Server. The user account is normally set not to expire. Otherwise, user credentials need to be renewed each time the account expires.
|
|
NameResolutionForLocalHost
|
Possible values are L (default), P, or E. Used to specify how the local (client) computer name is resolved, when the gethostbyname API is called. The LocalHost computer name is resolved by calling the Winsock API function gethostbyname() using the LocalHost string, an empty string, or a NULL string pointer. Winsock applications call gethostbyname(LocalHost) to find their local IP address and send it to an Internet server. When this option is set to L, gethostbyname() returns the IP addresses of the local host computer. When this option is set to P, gethostbyname() returns the IP addresses of the ISA Server computer. When this option is set to E, gethostbyname() returns only the external IP addresses of the ISA Server computer-those IP addresses that are not in the local address table.
|
|
ControlChannel
|
Possible values: Wsp.udp or Wsp.tcp (default). Specifies the type of control channel used.
|
|
EnableRouteMode
|
Possible values are 0 and 1 (default). When EnableRouteMode is set to 1 and a route relationship is configured between the Firewall Client computer and the requested destination, then the IP address of the Firewall client is used as the source address. When the value is set to 0, the IP address of the ISA Server computer is used. This flag does not apply to older versions of Firewall client.
|
| ISA 2004 Unsolved Mysteries |
ISA 2004 and the official Microsoft stance on this issue is that Firewall client publishing is not supported. We will keep you up to date on any information we receive on this and publish workarounds when available. You will also discover that the Firewall client settings you configure on the ISA 2004 firewall are not stored in the Firewall client configuration files located on the Firewall client machine. This is in contrast to how Firewall client configuration information was stored on ISA Server 2000 Firewall clients. The Firewall client configuration information is stored in memory and is not written to the hard disk. The reason for this, and why it is not documented, is an ISA 2004 Unsolved Mystery.
|
While the configuration files stored at the local Firewall client machine remain a bit of a mystery at the time we write this book, the centralized configuration of the Firewall client done at the Microsoft Internet Security and Acceleration Server 2004 management console remains as useful as it was in ISA Server 2000. You can access the centralized Firewall client configuration interface by opening the Microsoft Internet Security and Acceleration Server 2004 management console, then expanding the server name and the Configuration node. Click on the General node, and then click the Define Firewall Client Settings link.
Figure 5.18: The Define Firewall Client Settings link
Click the Application Settings tab. A list of the built-in Firewall client application settings is shown in Figure 5.19.
Figure 5.19: The Firewall Client Settings Dialog Box
These settings are applied to all Firewall clients who obtain their settings from the ISA 2004 firewall. For example, you can see a setting outlook Disable. This setting tells the Firewall client software to bypass the Firewall client settings for the Microsoft Outlook application. This is an important setting, which allows the Outlook client to receive the proper new mail notification messages.
One especially of the Firewall client settings feature is to block applications. For example, you may want to block users from using the kazaa.exe application. You can use the Disable key to block the application. Do the following to block the kazaa.exe application:
In the Firewall Client Settings dialog box, on the Application Settings tab, click New.
In the Application Entry Settings dialog box, enter Kazaa (without the file extension) in the Application text box. Select Disable from the Key drop-down list. Select the value 1 from the Value list.
Click OK.
The new entry for kazaa appears in the Settings list. Click Apply, and then OK.
Click Apply (Figure 5.20) to save the changes and update the firewall policy.
Figure 5.20: Apply Changes to Firewall Configuration
Click OK in the Apply New Configuration dialog box
At this point, any user that has the Firewall client software installed will not be able to use the kazaa.exe application.
| Warning! |
Users can get around this configuration by renaming the executable file. In order to completely block the kazaa application, you will need to configure the HTTP security filter and limit the users' access to only the HTTP protocol, or purchase a third-party application filter, such as the Akonix L7 for ISA Server product (www.akonix.com), that can detect peer-to-peer applications.
|
The Web Proxy client is any computer that has its browser configured to use the ISA 2004 firewall as its Web Proxy server. You do not need to add any new software to make a machine a Web Proxy client. The only requirement is that you configure the browser on the client machine to use the ISA 2004 firewall as its Web Proxy. The Web browser isn't the only application that can be configured as a Web Proxy client. Other applications, such as instant messengers and e-mail clients can also be configured as Web Proxy clients.
Advantages of the Web Proxy client configuration include:
Improved performance for the Firewall and SecureNAT client configuration for Web access
Ability to use the autoconfiguration script to bypass sites Direct Access
Allows you to provide Web access (HTTP/HTTPS/FTP download) without enabling access to other protocols.
Allows you to enforce user/group-based access controls over Web access.
Supports RADIUS authentication for outbound Web Proxy client requests
Allows you to limit the number of outbound Web Proxy client connections.
Supports Web Proxy chaining, which can further speed up Internet access
Web Proxy client machines communicate directly with the ISA 2004 firewall via the firewall's Web Proxy filter. The Web Proxy client connects directly to TCP port 8080 on the ISA 2004 firewall. TCP port 8080 is used by the ISA 2004 firewall's Web Proxy listener. The listener listens for outgoing Web requests and then exposes those communications to the firewall's Access Policies. Configuring the clients as Web Proxy clients improves performance because connections from Firewall and SecureNAT clients must be passed to the Web Proxy filter instead of being received directly by the filter. You will find during your own testing that Web Proxy client computers access Web content noticeably faster.
One of the most useful features of the Web Proxy client configuration is the ability to use Direct Access to bypass the Web Proxy filter for selected Web sites. This requires that the Web Proxy client computer be configured to use the autoconfiguration script. There are two ways you can configure the Web Proxy client to use the autoconfiguration script:
Manually configure the client to use the autoconfiguration script
Configure WPAD entries in DNS and /or DHCP and configure the Web Proxy client to use autodetection to access configuration information
You can manually configure the Web Proxy client browser to use the autoconfiguration script. Any application that pulls its configuration from the Web browser settings can typically take advantage of the autoconfiguration script settings. Applications that do not pull their configuration from the Web browser are unlikely to be able to benefit from the autoconfiguration script settings.
A more efficient method of assigning the autoconfiguration script to the Web Proxy clients is to use WPAD entries in DNS and/or DHCP. The WPAD information will point the Web Proxy client to the IP address of the ISA 2004 firewall, from which the Web Proxy client will obtain autoconfiguration settings.
Support for the autoconfiguration script is critical for Web Proxy clients who want to access certain Java sites and also Hotmail e-mail. The autoconfiguration script provides a centralized list of Web sites that should be accessed via Direct Access. When these sites are configured for Direct Access, the Web Proxy client computer will bypass the Web Proxy filter and allow other methods, such as the machine's SecureNAT and/or Firewall client configuration, to connect to the Web site.
The Web Proxy client configuration allows you to provide Internet access to users who do not require the full range of Internet protocols. The Web Proxy client handles only the HTTP, HTTPS (SSL) and HTTP-tunnel FTP download. If a user's computer is configured as only a Web Proxy client, that user will have access to those protocols and no others. In fact, you can limit users to only a subset of those protocols.
Web Proxy clients use a tunneled connection when they send their Internet requests to the ISA 2004 firewall. For example, when a user sends a request to www.microsoft.com, the Web Proxy client wraps this request in another HTTP header with the destination address being the ISA 2004 firewall computer's internal interface and the destination port TCP 8080. When the ISA 2004 firewall receives the request, it removes the Web Proxy client's header and forwards the request to the Internet server at www.microsoft.com.
In the same way, when a Web Proxy client sends an FTP request to a site, such as ftp://ftp.microsoft.com, the Web Proxy client wraps the FTP request in the same HTTP header with the destination address of the Internal interface of the ISA 2004 firewall and the destination port TCP 8080. When the ISA 2004 firewall receives this request, it removes the HTTP header and forwards the request to the FTP server at ftp.microsoft.com as an actual FTP request, not an HTTP request. This is why we refer to the Web Proxy client's FTP support as HTTP-tunneled FTP.
| Note |
When using the Web Proxy client for FTP connections, the Web Proxy FTP client can perform only FTP downloads. In order to support FTP uploads the client machine will need to be configured as a SecureNAT or Firewall client. In adddition, the requests forwarded by the Web Proxy are sent as PORT (standard) mode connections
|
The Web Proxy client is able to send user credentials to the ISA 2004 firewall computer when required. In contrast to the Firewall client, which always sends user credentials to the ISA 2004 firewall, the Web Proxy client only sends credentials when asked to provide them. This improves performance, as authentication is only performed when required.
If the Web Proxy client has access to an Access Rule that allows access to the site and content in the request, and if the Access Rule allows for anonymous access (allows 'All Users' access to the rule), then the Web Proxy client does not send credentials and the connection is allowed (assuming that the Access Rule is an 'allow' rule)
This feature explains many of the anonymous entries you have in your Web Proxy log files. When the Web Proxy client sends a request to the ISA 2004 firewall, the first connection attempt does not include the Web Proxy client user credentials. This is logged as an anonymous request. If access to the site requires user credentials, then the ISA 2004 firewall will send an 'access denied' message to the Web Proxy client machine and request the user to authenticate. Figure 5.21 illustrates that, at this point, the Web Proxy client has the option to authenticate using a number of different authentication protocols.
Figure 5.21: The Authentication Dialog Box
You can use the following authentication protocols for Web Proxy sessions:
Windows-Integrated authentication
Basic authentication
Digest authentication
Client Certificate authentication
RADIUS authentication
| Warning |
Web browsers can use Integrated, Basic, Digest, RADIUS, and Client Certificate authentication. It's important to note that Web browsers can only use Client Certificate authentication when connecting to published resources through a Web Publishing Rule. Web browser clients acting as Web Proxy clients cannot use Client Certificate authentication when accessing resources through the ISA 2004 firewall via an Access Rule. However, a downstream ISA 2004 firewall can use client certificate authentication to authenticate to an upstream ISA 2004 firewall in a WebProxy chaining scenario.
|
Credentials are passed to the ISA 2004 firewall transparently when Integrated authentication is enabled. However, both the ISA 2004 firewall and the Web Proxy client must be members of the same domain (or the ISA 2004 firewall must be a member of a domain that trusts the user account domain), or the ISA 2004 firewall must use RADIUS authentication to connect to the Active Directory or Windows NT 4.0 user account database. You can also get transparent authentication if you mirror user accounts in the local Security Account Manager (SAM) on the ISA 2004 firewall computer. However, for any but the smallest of organizations, the administrative overhead and the security risks of mirroring user accounts can be unacceptably high.
SSL certificate authentication is currently not available for browser to Web Proxy server connections. You can use SSL certificate authentication when configuring Web Proxy chaining. In this setup, a downstream Web Proxy server forwards Web requests to an upstream Web Proxy server. The downstream ISA 2004 Web Proxy server can authenticate with the upstream server by presenting a client certificate to the upstream ISA 2004 Web Proxy server. This provides a very secure Web Proxy chaining configuration that is not easily attainable with other Web Proxy solutions.
Users are prompted for user name and password when only Basic authentication is used. If the Web Proxy client and the ISA 2004 firewall are not members of the same domain, or if RADIUS authentication is not used, then Basic authentication is the best solution.
A new feature included with ISA 2004 is the ability to use RADIUS for Web Proxy authentication. When RADIUS is enabled as an authentication protocol for Web Proxy clients, the ISA 2004 firewall does not need to be a member of the user domain. This provides a slightly higher level of security because an attacker who may take control of the ISA 2004 firewall will not be able to leverage domain credentials to attack users on the protected network behind the ISA 2004 firewall. When a domain user tries to authenticate for a Web connection, the ISA 2004 firewall that is not a member of the user domain forwards the authentication request to a RADIUS server on the Internal network. The RADIUS server forwards the request to an authentication server and then returns the response to the ISA 2004 firewall.
Note that when you configure the ISA 2004 firewall to support RADIUS authentication, the ISA 2004 firewall becomes a RADIUS client. You can use any RADIUS server, including Microsoft's RADIUS implementation, the Internet Authentication Server (IAS).
RADIUS authentication does require that you create a RADIUS server on the Internal network and configure the Web Proxy listener for the Web Proxy client's network to use the RADIUS server. In addition, there must be an Access Rule allowing the ISA 2004 firewall to communicate with the RADIUS server using the RADIUS protocol. There is a default firewall System Policy allowing RADIUS messages to the Internal network. If your RADIUS server is not located on the Internal network, you will need to configure the firewall System Policy allowing the RADIUS protocol to the RADIUS server at the alternate location.
We will go through the procedures required to create the RADIUS server and configure the RADIUS client later in this chapter. However, in order to support Web Proxy clients, you will need to perform the following:
Configure the Outgoing Web Requests listener to use RADIUS authentication
Configure the user account for Remote Access Permission or configure Remote Access Policy to enable access
Configure the Remote Access Policy to support PAP authentication
Do the following to configure the Web Proxy listener on the Web Proxy client's Network to use RADIUS:
In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name and then expand the Configuration node. Click on the Networks node and right-click on the Internal network (assuming that the Web Proxy clients are located on the Internal network, you would choose the appropriate network in your own configuration). Click Properties.
In the Internal Properties dialog box, click the Web Proxy tab.
On the Web Proxy tab, click the Authentication button.
In the Authentication dialog box, remove the checkmarks from the all the other check boxes. You will see dialog boxes informing you that there are no authentication methods available. Confirm that you have only the RADIUS option selected (see Figure 5.22) Do not select the Require all users to authenticate option. There have been many instances where this option causes repeated authentication boxes to appear..
Figure 5.22: The Authentication Dialog Box.
Click RADIUS Servers.
In the Add RADIUS Server dialog box, shown in Figure 5.23, enter a name or IP address for the RADIUS server in the Server name text box. If you enter a name, make sure that it's a fully-qualified domain name and that the ISA 2004 firewall can resolve that name to the correct IP address. Enter a description for the server in the Server description text box. Leave the Port and Time-out (seconds) values at their defaults unless you have a reason to change them. Confirm that there is a checkmark in the Always use message authenticator check box.
Figure 5.23: The Add RADIUS Server Dialog Box.
In the Shared Secret dialog box, enter and confirm a password in the New secret and Confirm new secret text boxes. This password is used to authenticate the RADIUS server and RADIUS client. Make sure that this is the same password you used when you configured the RADIUS client on the RADIUS server for the Internal network. Click OK. (NOTE: The RADIUS password should be long and complex; an ideal RADIUS password is one that is 24 characters and is created with a password generator application. The shared secret is used to generate an MD5 hash, which is used to authenticate the RADIUS client to the RADIUS server).
Click OK in the Add RADIUS Server dialog box.
The RADIUS server entry now appears on the list. Note that you can create multiple RADIUS servers and they will be queried in the order listed.
Click OK in the Authentication dialog box.
Click Apply and OK in the Internal Properties dialog box.
Click Apply to save the changes and update the firewall policy.
Click OK in the Apply New Configuration dialog box.
The next step is to configure the user account to enable dial-in access. Note that this procedure is not required if the domain is in Windows 2000 or Windows Server 2003 Native Mode. The reason for this is that you can control access policy via Remote Access Policy, and the default setting for user accounts controls access via Remote Access Policy when the domain is in Native Mode. For this reason, we highly recommend that you configure your Windows domains in Native Mode so that you do not need to enable each individual user account for dial-in access.
In the Active Directory Users and Computers console on a domain controller that contains the user accounts that you want to authenticate with Web Proxy RADIUS authentication, double-click on the account you want to allow to use RADIUS authentication.
In the user's Properties dialog box, click the Dial-in tab.
On the Dial-in tab, select the Allow access option.
Click Apply, and then click OK.
The user account is now able to use RADIUS for Web Proxy authentication.
The last step is to configure the Remote Access Policy so that PAP authentication is supported for Web Proxy client RADIUS authentication. It's important to note that PAP authentication is not secure, and you should use some method to protect the credentials as they as pass between the ISA 2004 firewall and the RADIUS server. Although the credentials are encyrpted using an MD5 hash, there should still be an additional layer of protection. The preferred method of protecting credentials is to use an IPSec transport mode connection.
Do the following to configure the Remote Access Policy:
At the IAS server on the Internal network, click Start, and point to Administrative Tools. Click Internet Authentication Services.
In the Internet Authentication Services console, click the Remote Access Policies node in the left pane of the console.
On the Remote Access Policies node, note that there are two Remote Access Policies in the right pane of the console. The first policy applies only to RAS connections from dial-up and VPN clients. The second policy, Connections to other access servers is the one used by the Web Proxy clients. Double-click Connection to other access servers.
In the Connections to other access servers Properties dialog box, click Edit Profile.
In the Edit Dial-in Profile dialog box, click the Authentication tab.
On the Authentication tab, put a checkmark in the Unencrypted authentication (PAP, SPAP) check box.
Click Apply and OK.
In the Connections to other access servers Properties dialog box (see Figure 5.24), confirm that the condition Windows-Groups matches… entry is included. This includes the groups of users who you want to have access to the Web Proxy service via RADIUS authentication. Use the Add button to add the group you want to have access. Also, confirm that the Grant remote access permission option is selected.
Figure 5.24: The Connections to other Access Servers Properties Dialog Box
Click Apply and OK in the Connections to other access server Properties dialog box.
The policy will take effect immediately; you do not need to restart any equipment.
The number of Web Proxy client connections can be limited to a number that you specify. This can be helpful when you have limited bandwidth or you want to make sure that only a certain percentage of your users have access to the Internet at any single point in time.
You can access the configuration interface for the number of simultaneous Web Proxy client connections in the Properties dialog box of the network from which the Web Proxy clients access the Web. In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name, and then expand the Configuration node. Click the Networks node in the left pane of the console, and right-click the network in the Details pane. Click the Properties command.
In the network's Properties dialog box, click the Web Proxy tab. On the Web Proxy tab, click Advanced. In the Advanced Settings dialog box depicted in Figure 5.25, you can chose from the Unlimited and the Maximum options. When you select the Maximum option, you can enter a value for the maximum number of simultaneous connections. There is also a Connection timeout (seconds) value that you can customize. The default value is 120 seconds. You can shorten or extend this value depending on your requirements. If you find that idle connections are using up the number of allowed simultaneous connections, you can shorten the timeout value. If you find that users complain about Web sessions being disconnected prematurely, you can extend the timeout value.
Figure 5.25: Advanced Settings
Web Proxy chaining allows you to connect ISA 2004 and ISA Server 2000 firewall and Web Proxy servers to each other. The firewall Web Proxy servers represent a chain, where the ISA Web Proxy server farthest away from the central Internet access point represents the most 'downstream' Web Proxy, and the ISA Web Proxy closest to the central Internet connection is the most 'upstream' ISA Web Proxy.
There are a number of scenarios where ISA Web Proxy chaining can be configured. These scenarios include:
Branch offices connecting to a main office ISA 2004 Web proxy firewall server
Campus networks with multiple workgroup/departmental LANs connecting to upstream ISA 2004 firewall Web Proxies upstream on a campus backbone or services network
Back-to-back ISA 2004 firewall configurations where the downstream ISA 2004 firewall uses Web Proxy chaining to forward corporate network Web Proxy requests to the front-end ISA 2004 firewall. This configuration adds to the already-strong security of the back-to-back ISA 2004 firewall configuration.
We will go into these scenarios in detail in Chapter 10 Accelerating Web Performance with ISA 2004 Caching Capabilities. Table 5.7 illustrates the advantages of the WebProxy client configuration.
|
Web Proxy Client Advantage
|
Implication
|
|---|---|
|
Improved performance over Firewall client only, SecureNAT conclient only, or Firewall/SecureNAT client only configurations
|
Machine configured as Web Proxy clients exhibit superior performance when necting to the Internet using Web protocols. Connect requests are forwarded directly to the Web Proxy filter and connections that do not require authentication are allowed immediately. The Web Proxy will only request credentials when a connection requires authentication.
|
|
Ability to use autoconfiguration
|
Web Proxy clients can use Direct Access to script for Direct Access avoid using the Web Proxy when connecting to sites that do not support connections through Web Proxy servers. A Web Proxy client configured with the autoconfiguration script can be instructed to avoid the Web Proxy filter when connecting to Java sites or when connecting to Hotmail using Outlook Express. Without the autoconfiguration script and Direct Access, the user would have to manually disable the Web Proxy configuration on the client to avoid the connecting via the Web Proxy.
|
|
Allows you to limit access to only "Web" protocols
|
Machines configured as only Web Proxy clients have access to the HTTP, HTTPS and FTP (download) protocols only.
|
|
Allows you to granular user/group based access controls for Web access
|
Web Proxy clients can send user credentials to the ISA firewall when required. This enables you to set fine-tuned granular access controls over what sites and content can be access on a per user/per group basis.
|
|
Supports RADIUS authentication for outbound Web Proxy requests
|
RADIUS authentication allows you to authenticate against any authentication server that supports RADIUS authentication. An Active Directory domain controller is one example of such an authentication server. RADIUS allows your Active Directory users to authenticate with the Web Proxy, even when the ISA firewall does not belong to the same Active Directory domain as the users.
|
|
Allows you to put Limits on the number of outbound connections
|
You can configure a limit on the number of Web Proxy client connections allowed to Web Proxy clients. Once that limit is reached, no more Web Proxy client connection are allowed through the ISA firewall. That provides a method of throttling Internet access without requiring strict bandwidth control.
|
|
Supports Web Proxy chaining
|
Web Proxy clients can directly benefit from Web Proxy chaining configurations where multiple ISA firewalls are configured in a Web Proxy chain. Authentication information from the Web Proxy client can be forwarded to upstream Web Proxy servers in the ISA firewall Web Proxy chain. The Web Proxy chaining configuration can provide significant improved performance for remote offices and machines located behind busy backbone network segments.
|
|
Web Proxy Client Disadvantage
|
Implication
|
|---|---|
|
None
|
There are no disadvantages to the Web Proxy
|
|
client configuration. All machines should be
|
|
|
configured as Web Proxy clients to improve
|
|
|
performance and Internet access control.
|
A common point of confusion among ISA 2004 firewall administrators is whether or not a machine can be configured as multiple ISA 2004 client types. Many ISA firewall administrators are under the impression that a single machine cannot be configured as a Web Proxy, Firewall, and SecureNAT client.. This is a misconception. It is possible and sometimes preferred that a single computer be configured as all three types of ISA client.
The truth is that a single machine cannot be configured to act as both a Firewall client and a SecureNAT client. The reason for this is when a machine is configured as a Firewall client, all Winsock TCP and UDP communications are intercepted by the Firewall client software. Therefore, the SecureNAT client configuration does not have access to these communications. For non-Winsock TCP and UDP communications, and for all other non-TCP/UDP communications, the SecureNAT client handles the requests. For example, if the machine is configured as both a SecureNAT and Firewall client, the SecureNAT client configuration handles all ping, tracert and PPTP connections. Ping and tracert use ICMP, and PPTP uses GRE. Neither ICMP nor GRE uses TCP or UDP as a transport.
Table 5.9 describes the behavior of machines that are configured as multiple client types.
|
ISA 2004 Client Configuration
|
Application Behavior
|
|---|---|
|
SecureNAT and Firewall Client
|
Firewall client handles all TCP and UDP communications from Winsock applications. SecureNAT client handles all TCP/UDP communications from non-Winsock applications and all non-TCP/UDP communications
|
|
SecureNAT and Web Proxy Client
|
Web Proxy client handles HTTP/HTTPS/FTP download communications from the Web Proxy client application. From non-Web Proxy client applications, the SecureNAT client handles the HTTP/HTTP/FTP connections (both download and upload). If the Web Proxy client-configured browser is not able to use the Web Proxy service to access FTP resources, the client will 'fall back' on the SecureNAT client configuration. All other protocols are handled by the SecureNAT client configuration.
|
|
Firewall and Web Proxy Client
|
The Web Proxy client configuration handles HTTP/HTTPS/FTP download from Web Proxy client-configured applications. The Firewall client handles all other Winsock TCP and UDP communications, including HTTP/HTTPS/FTP download and upload from applications not configured as Web Proxy clients. FTP download from Web Proxy clients can fall back on Firewall client configuration. No access to non-TCP/UDP protocols and no access to TCP and UDP protocols for non-Winsock applications.
|
|
SecureNAT, Firewall, and Web Proxy Client
|
Access to HTTP/HTTPS/FTP download via Web Proxy client configuration for applications configured as Web Proxy clients. Fall back to Firewall client configuration for FTP download if Web Proxy client configuration does not support connection. All TCP/UDP communications from Winsock applications handled by Firewall client. All other communications handled by SecureNAT client configuration.
|
The ISA 2004 client type you decide on depends on the level of functionality and level of security you require. Table 5.10 rates the various ISA 2004 clients, based on functionality, security, ease of deployment and management, and operating system compatibility.
|
Functionality
|
Security
|
Ease of Deployment and Management
|
Operating System Compatibility
|
|---|---|---|---|
|
Firewall client
|
Firewall client
|
SecureNAT client
|
SecureNAT client
|
|
SecureNAT client
|
Web Proxy client
|
Web Proxy client
|
Web Proxy client
|
|
Web Proxy
|
SecureNAT client
|
Firewall Client
|
Firewall client
|
Table 5.11 describes a number of parameters you should consider when selecting the ISA 2004 client type to use in your environment.
|
You require:
|
Suggested ISA 2004 Client type:
|
|---|---|
|
No software deployment to network clients.
|
The SecureNAT and Web Proxy client. The SecureNAT client does not require software installation and only requires that you set the appropriate default gateway address. The Web Proxy client does not require client software installation; you only need to configure the Web Proxy applications to use the firewall as their Web Proxy server.
|
|
Only Web protocols: HTTP, HTTPS and FTP download through a Web browser and other Web Proxy- aware applications and Web caching.
|
Web Proxy client or SecureNAT client. Both of these clients will be able to benefit from the Web Proxy cache on the ISA 2004 firewall. The advantage to using the Web Proxy client over the SecureNAT client in this scenario is that the Web Proxy client will send user information to the ISA 2004 firewall and allow you to enforce strong user/group-based access control over what sites and content users access via the Web.
|
|
Authentication before allowing access. User name included in logs.
|
Firewall or Web Proxy client. The Web Proxy client enables you to enforce user/group-based strong access control over HTTP/HTTPS/FTP download connections via Web Proxy client applications. The Firewall client allows strong user/group-based access controls over all Winsock applications using TCP and UDP protocols. Whenever a user authenticates with the ISA 2004 firewall, that user's name is included in the logs.
|
|
Servers published to the The Internet using Web or Server Publishing Rules
|
The published server must be configured as a SecureNAT client if the original Internet client IP address is retained in the communication reaching the published server. This is the default configuration for Server Publishing Rules. For Web Publishing Rules, the default is to replace the original client IP address with the IP address of the ISA 2004 firewall's Internal interface (the interface that lies on the same Network as the published server). When the original source IP address is replaced with the ISA 2004 firewall's IP address, the published server only needs to know the route to the Internal IP address of the ISA 2004 firewall that forwarded the request. Note that for both Web and Server Publishing Rules you have the option to preserve the original client IP address.
|
|
Support for non-Windows operating systems
|
SecureNAT and Web Proxy clients. All operating systems support the SecureNAT client configuration because the SecureNAT client only requires the appropriate default gateway address configuration. All operating systems running applications supporting Web Proxy client configuration can connect to the ISA 2004 firewall via the Web Proxy client.
|
|
Support for Internet games
|
Firewall client. Most Internet games require multiple primary and secondary connections. Only the Firewall client supports complex protocols requiring secondary connections (unless there is an application filter installed on the ISA 2004 firewall to support that specific application).
|
|
Support for Voice/Video applications
|
Voice and video applications that do not require Session Initiation Protocol (SIP) generally require secondary connections (ISA 2004 does not support SIP signaling). Only the Firewall client supports secondary connections without the aid of an application filter.
|