Chapter 6: Installing and Configuring the ISA Firewall Software - Dr. Tom Shinderamp;#039;s Configuring ISA Server 1002004 [Electronic resources] نسخه متنی

Chapter 6: Installing and Configuring the ISA Firewall Software

Pre-installation Tasks and Considerations

There are several key pre-installation and tasks and considerations you need to address before installing the ISA firewall software. These include:

System Requirements

Configuring the Routing Table

DNS Server Placement

Configuring the ISA Firewall's Network Interfaces

Unattended Installation

Installation via a Terminal Services Administration Mode Session

System Requirements

The following are requirements for installing the ISA firewall software:

Intel or AMD system with a 550 megahertz (MHz) or higher processor

Windows 2000 or Windows Server 2003 operating system

A minimum of 256 megabytes (MB) of memory; a practical minimum of 512 MB of memory for non-Web caching systems, and 1000 MB for Web-caching ISA firewalls

At least one network adapter; two or more network adapters are required to obtain stateful filtering and stateful application-layer inspection firewall functionality

An additional network adapter for each network connected to the ISA Server computer

One local hard-disk partition that is formatted with the NTFS file system, and at least 150 MB of available hard disk space (this is exclusive of hard-disk space you want to use for caching)

Additional disk space, which ideally is on a separate spindle, if you plan on using the ISA firewall's Web-caching feature

Special installation issues if you plan on installing the ISA firewall software on Windows 2000 include:

Windows 2000 Service Pack 4 (SP4), or later, must be installed.

Internet Explorer 6, or later, must be installed.

If you are using the Windows 2000 SP4 slipstream, you must also install the hotfix specified in article 821887, 'Events for Authorization Roles Are Not Logged in the Security Log When You Configure Auditing for Windows 2000 Authorization Manager Runtime,' in the Microsoft Knowledge Base at http://support.microsoft.com/default.aspx?scid=kb;en-us;821887.

You cannot configure the L2TP IPSec pre-shared key.

VPN Quarantine is not supported when using RADIUS policy.

All ISA Server services run using the local system account.

Another important consideration is capacity planning. While the above reflects minimal system requirements for installing and running the ISA firewall software, the ideal configuration is obtained when you size the hardware to optimize the ISA firewall software performance for your site. Table 6.1 provides basic guidelines regarding processor, memory, disk space and network adapter requirements based on Internet link speed.

For an exceptionally thorough and comprehensive discussion on ISA firewall performance optimization and sizing, please refer to the Microsoft document ISA Server 2004 Performance Best Practices at www.microsoft.com/technet/prodtechnol/isa/2004/plan/bestpractices.mspx.

Configuring the Routing Table

The routing table on the ISA firewall machine should be configured before you install the ISA firewall software. The routing table should include routes to all networks that are not local to the ISA firewall's network interfaces. These routing table entries are required because the ISA firewall can have only a single default gateway. Normally, the default gateway is configured on the network interface that is used for the External Network. Therefore, if you have an internal or or other Network that contains multiple subnets, you should configure routing table entries that ensure the ISA firewall can communicate with the computers and other IP devices on the appropriate subnets. The network interface with the default gateway is the one used to connect to the Internet, either direction or via upstream routers.

The routing table entries are critical to support the ISA firewall's 'network-within-a-Network' scenarios. A network within a Network is a network ID located behind a NIC on the ISA firewall that is a non-local network.

For example, Figure 6.1 is an example of a simple network-within-a-Network scenario.

Figure 6.1: Network within a Network

This small organization's IP addressing scheme uses two network IDs for the corporate network: 192.168.1.0/24 and 192.168.2.0/24. The network local to the ISA firewall's internal interface is 192.168.1.0/24. The network remote from the ISA firewall's internal interface is 192.168.2.0/24. A corporate network router separates the network and routes packets between these two network IDs.

The ISA firewall's networking model includes both of these networks as part of the same Network (Note: A capital 'N' indicates an ISA firewall-defined network). You would naturally assume that the 192.168.1.0/24 would be an ISA-defined Network since it includes an entire network ID, but you might also assume that network ID 192.168.2.0/24 would be defined as a second ISA firewall-defined Network. That would be incorrect because the ISA firewall's Network model includes all networks (all IP addresses) reachable from a specific interface on the ISA firewall as being part of the same network.

The rationale behind this is that hosts on the same ISA-defined Network do not use the ISA firewall to mediate communications between themselves. It makes no sense for the ISA firewall to mediate communications between hosts on networks IDs 192.168.1.0/24 and 192.168.2.0/24, as this would require hosts to loop back through the firewall to reach hosts to which they should directly communicate.

In this example, there should be a routing table entry on the ISA firewall indicating that in order to reach network ID 192.168.2.0/24, the connection must be forwarded to IP address 192.168.2.1 on the corporate router. You can use either the RRAS console or the command line ROUTE and netsh commands to add the routing table entry.

The ISA firewall must know the route to each internal network ID. If you find that connections are not being correctly forwarded by the ISA firewall to hosts on the corporate network, confirm that there are routing table entries on the ISA firewall indicating the correct gateway for each of those network IDs.

DNS Server Placement

DNS server and host name resolution issues represent the most common ISA firewall connectivity problems. Name resolution for both corporate network and Internet hosts must be performed correctly. If the company's name resolution infrastructure isn't properly configured, one of the first victims of the flawed name resolution design will be the ISA firewall.

The ISA firewall must be able to correctly resolve both corporate and Internet DNS names. The ISA firewall performs name resolution for both Web Proxy and Firewall clients. If the firewall cannot perform name resolution correctly, Internet connectivity for both Web Proxy and Firewall clients will fail.

Correct name resolution for corporate network resources is also critical because the ISA firewall must be able to correctly resolve names for corporate network resources published via Web Publishing rules. For example, when you create a secure-SSL Web Publishing Rule, the ISA firewall must be able to correctly forward incoming connection requests to the FQDN used for the common name on the Web site certificate bound to the published Web server on the corporate network.

The ideal name resolution infrastructure is the split DNS. The split-DNS infrastructure allows external hosts to resolve names to publicly-accessible addresses and corporate network hosts to resolve names to privately-accessible addresses. Figure 6.2 depicts how a split-DNS infrastructure works to enhance name resolution for hosts inside your corporate network, as well as those that roam between the corporate network and remote locations on the Internet.

Figure 6.2: The Miracle of the Split-DNS Infrastructure

A user at a remote location needs to access resources on the corporate Web server, www.msfirewall.org. The www.msfirewall.org Web server is hosted on an ISA firewall-Protected Network and published using an ISA firewall Web Publishing Rule. The remote user sends a request to www.msfirewall.org, and the name is resolved by the public DNS server authoritative for the msfirewall.org domain. The name is resolved to an IP address on the external interface of the ISA firewall used by the Web listener designated in the Web Publishing Rule.

The remote Web client sends the request to the IP address on the external interface used by the Web Publishing Rules Web listener.

The ISA firewall resolves the name www.msfirewall.org to the actual IP address bound to the www.msfirewall.org Web site on the corporate network by querying the Internal network DNS server authoritative for the msfirewall.org domain.

The ISA firewall forwards the connection to the actual IP address bound to the www.msfirewall.org Web site on the corporate network.

A host on the corporate network needs to access resources on the www.msfirewall.org Web site. The corporate user sends a request to the corporate DNS server that is authoritative for the msfirewall.org domain. The corporate DNS server resolves the name www.msfirewall.org to the actual IP address bound to the www.msfirewall.org Web site on the corporate network.

The Web client on the corporate network connects directly to the www.msfirewall.org Web server. The Web client doesn't loop back to reach the www.msfirewall.org Web site on the corporate network because Web Proxy clients are configured for direct access to resources on the msfirewall.org domain.

The split-DNS infrastructure provides transparent access to resources for users regardless of their location. Users can move between the corporate network and remote locations and use the same name to reach the same corporate resources. They don't need to reconfigure their mail clients, news clients, and other applications because the same name is used to access the resources regardless of location. Any organization needing to support users that roam between the corporate network and remote locations should implement a split DNS infrastructure.

Requirements for the split-DNS infrastructure include:

A DNS server authoritative for the domain that resolves names for resources for that domain to the internal addresses used to access those resources

A DNS server authoritative for the domain that resolves names for resources in that domain to the publicly-accessible addresses used to access those resources

Remote users must be assigned DNS server addresses that forward requests for the domain to a public DNS server. This is easily accomplished using DHCP.

Corporate users must be assigned DNS server addresses that forward requests for the domain to the private DNS server. This is easily accomplished using DHCP.

The ISA firewall must be able to resolve names of published resources and all other resources hosted on a ISA firewall-Protected Network to the private address used to access that resource.

Most organizations that use the ISA firewall will have one or more internal DNS servers. At least one of those DNS servers should be configured to resolve both internal and Internet host names, and the ISA firewall should be configured to use that DNS server. If you have an internal network DNS server, you should never configure the ISA firewall's interfaces to use an external DNS server. This is a common mistake and can lead to slow or failed name resolution attempts.

Configuring the ISA Firewall's Network Interfaces

Perhaps one of the least understood ISA firewall configuration issues is how to correctly configure the IP addressing information on the ISA firewall's network interfaces. The reason for this is that name resolution issues have the potential for being complex, and fledging firewall administrators are often too busy to get lost in the details of DNS host name and NetBIOS name resolution.

There are two main networks interface configuration scenarios:

An established name-resolution infrastructure on the corporate network protected by the ISA firewall

No established name-resolution infrastructure on the corporate network protected by the ISA firewall

Tables 6.2 and 6.3 show the correct IP addressing information for both these scenarios in dual-homed ISA firewalls.

You should already be familiar with configuring IP addressing information for Windows Server interfaces. However, you may not be aware of how to change the interface order. The interface order is used to determine what name server addresses should be used preferentially.

Perform the following steps to change the interface order:

Right-click My Network Places on the desktop, and click Properties.

In the Network and Dial-up Connections window, click the Advanced menu, then click Advanced Settings.

In the Advanced Settings dialog box (Figure 6.3), click the internal interface in the list of Connections on the Adapters and Bindings tab. After selecting the internal interface, click the up-arrow to move the internal interface to the top of the list of interfaces.

Figure 6.3: The Advanced Settings Dialog Box

Click OK in the Advanced Settings dialog box.

Unattended Installation

You can perform an unattended installation of the ISA firewall to simplify provisioning multiple ISA firewalls using a common installation and configuration scheme. The unintended installation depends on the proper configuration of the msiund.ini file, which contains the configuration information used by ISA firewall setup in unattended mode.

The default msisaund.ini file is located on the ISA Server 2004 CD in the \FPC directory. Table 6.4 contains the salient entries and values that are configured in the msisaund.ini file.

Perform the following steps to effect the unattended installation of the ISA firewall:

Modify the Msisaund.ini file.

At a command prompt, enter

PathToISASetup\Setup.exe [/[X|R]] /V" /q[b|n] FULLPATHANSWERFILE=\"PathToINIFile\MSISAUND.INI\" 
PathToISASetup 

The path to the ISA Server 2004 installation files. The path may be the root folder of the ISA Server CD-ROM or a shared folder on your network that contains the ISA Server files.

/Q [b|n] 

Performs quiet unattended setup. If you specify b, a progress bar indicates the setup process. If you specify n, no dialog boxes are displayed.

/R 

Performs unattended reinstallation

/X 

Performs unattended uninstallation

PathToINIFile 

The path to the folder containing the unattended installation information

Issues related to unattended installation of the ISA firewall include:

You must be a member of the Administrators group to perform an unattended installation.

You cannot perform an unattended installation on a computer with ISA Server 2000 installed.

The INTERNALNETRANGES property in Msisaund.ini must specify at least one Internet Protocol (IP) address range that includes one of the IP addresses of your ISA Server computer. Otherwise, Setup fails.

A sample answer file (Msisaund.ini) is provided on the CD, in the FPC folder.

For example, CD\FPC\setup.exe /v' /qn FULLPATHANSWERFILE=\'C:\MSISAUND.INI\ performs an unattended installation of ISA Server, using the Msisaund.ini file located in c:\.

The MSDE component which is installed when you install the Advanced logging feature is not properly installed when you remotely install the ISA firewall using Terminal Services in application server mode. Use Terminal Services in administration mode to properly install MSDE.

Installation via a Terminal Services Administration Mode Session

You can install the ISA firewall via an Admin mode Terminal services connection. After installing is complete, a System Policy rule is configured to allow RDP connections only from the IP address of the machine that was connected during the ISA firewall software installation. This is in contrast to the default System Policy setting when installing the ISA firewall software at the console, where any host on the Internal Network can initiate an RDP connection to the ISA firewalls Internal interface.