A firewall is a device for controlling the flow of data between two parts of a network that are at different levels of trust. There are many ways to use firewalls to help secure an Internet site. They can be placed in front of the Web farm or behind the Web farm, or an additional connection can be created on the firewall and the Web servers can be placed on that network. The decision on how to use the firewalls in the final network design is based on application, management, and availability requirements.

The Microsoft® Systems Architecture Internet Data Center design implements redundant firewalls to enable faster and more reliable communication and to maintain high availability in a failover configuration.

Common Firewall Functionality

Before we dive into the firewall design details, let’s first set the stage by defining various firewall features as these will impact firewall selection options. Subsequent sections will examine the implementation specific details for these firewall options.

The firewall functionality definition found at the beginning of this chapter a is a good high level description. However, the implementation details of how this control over traffic is defined and implemented varies from vendor to vendor and product to product. While vendor specific firewall implementation can combine some or all of the features described below, in general there are four types of firewall devices:

·         Packet filtering firewalls

·         Application-level gateways, a.k.a. proxy servers

·         Circuit-level gateways

·         Stateful packet inspection (SPI) firewalls

Packet Filtering Firewalls

Packet filtering firewalls provide security by having to explicitly define the allowed traffic across the device. This means that each connection type needs to be defined on the packet filtering firewall in order for the communication to succeed. Packet filters can base their forwarding decisions on the protocol type (i.e. GRE, UDP, TCP ICMP to name a few), source/destination IP address or IP network (collection of IP addresses), source/destination ports or combination of any of these parameters. Some of the advantages of packet filtering are:

·         Less overhead than SPI (see below)

·         Low cost

·         Granular traffic control

Some of the drawbacks of packet filtering firewalls are:

·         No user authentication

·         No visibility beyond protocol/ports

·         Vulnerable to IP spoofing

For a more detailed discussion of the packet filtering, see the Basic TCP/IP Flow section below.

Proxy Servers

Application gateways provide security by requiring the clients to submit all requests for access to outside resources to the proxy server. This server then “proxies” the request to the intended Internet resource. Clearly, for client applications to take advantage of the proxy functionality they must be “proxy” aware so that they know where to send their requests. The most commonly encountered application gateway is the web proxy. Most of the popular web browsers are proxy aware and therefore able to take advantage of this architecture. Since all traffic is proxied via proxy server, this provides enhanced security. Note that each type of connection to Internet resources results in the establishment of two connections: one from the client to the proxy and a second from the proxy to the Internet resource. This means that clients are never directly in communication with Internet resources. Some of the advantages of proxy servers are:

·         The architecture’s intrinsically enhanced security

·         User or group-based authentication and access control

·         Traffic logging

·         Caching

Some of the disadvantages of a proxy server are:

·         The need for applications to be proxy aware

·         The need for proxy configuration on the client

·         Not all Internet applications are proxy aware

Circuit-level Gateways

Although proxy servers can provide enhanced security, a major drawback is their lack of transparency. This not an issue when dealing with a well-defined set of applications which support proxies. However, some obscure applications do not support proxies and therefore will not work. In such cases, circuit-level proxies can provide a solution. As the name implies, circuit-level proxy functionality is not based on a  proxy server understanding different protocols and how to handle them. Instead, it establishes connections for internal clients to Internet hosts on the client’s behalf. As with application proxy functionality, two connections are established. However, this happens at the connection level instead of at the application level. An example of a circuit-level proxy is the WINSOCK implementation on the WIN32 platform.

For applications to be circuit-level gateway compatible, they need to leverage platform-specific APIs to establish connections. For Windows applications to leverage this, they need to use WINSOCK Application Programming Interfaces (API) to establish external connections. Circuit-level gateway functionality also requires client-side software deployment. Some of the advantages of circuit-level gateways are:

·         Compatibility with any application using the WINSOCK API – this includes many WIN32 applications.

·         The architecture’s intrinsically enhanced security

·         User or group-based authentication and access control

·         Traffic logging

·         Support for more complex communication requirements (callbacks, etc.)

Some of the disadvantages are:

·         The need for client deployment

·         Lack of compatibility with applications which do not use platform APIs

·         Permit access for more complex applications and hence more complex security

Stateful Packet Inspection

The more recent class of firewall devices support Stateful Pa cket Inspection (SPI). While in the past this was a unique feature, this is now fairly common for any enterprise-scale firewall device. As the name implies, the major advantage that SPI firewalls provide is increased intelligence in the inspection of packets. Two main advantages of SPI firewalls are:

·         An enhanced understanding of the connection state through use of established connection table to reduce the likelihood of packet spoofing

·         The ability to examine packets based on a specific understanding of the common protocol utilized, such as SMTP or NNTP

SPI firewalls are more intelligent and provide enhanced security. However, the protocol-specific functionality may not be as extensive as that provided by a proxy server. This drawback is offset by the greater throughput of such devices in comparison to classical proxy servers.

Other Considerations

In addition to the four classes of firewalls defined above, there are other important features that need to be understood for proper solution selection. These are:

·         Network Address Translation - NAT (Static/Dynamic)

·         Port Address Translation PAT (Static/Dynamic)

·         Screened vs. NATed subnets and hosts

Next we examine each and their implications for IDC design.

Network Address Translation

NAT is a very common feature of nearly all firewall devices today. NAT allows the firewall devices to obscure the internal clients IP addresses. This is often required as many of the internal networks today utilize reserved private IP address ranges which are not routable on the Internet. NAT functionality can be either static or dynamic depending on the implementation. Static simply refers to the predetermined mapping between the internal non-routable IP addresses and the external public addresses. Dynamic mapping is determined at the time client is making a connection. Proxy servers by default perform NAT so that to the Internet resource, the requests are coming from the proxy server’s IP address.

Port Address Translation

PAT provides very similar functionality to NAT, but as name suggests, the translation is port-based rather than IP address-based.

NATed vs. Screened

One other significant consideration for IDC Firewall design deals with how the firewall protects its clients. Certain protocols such as Kerberos and IPSec encapsulate the source and destination addresses of the interacting hosts in the packet payload. Since such a payload is encrypted, an intermediate device such as a firewall would need to understand these protocols in order to make the necessary IP addressing modifications to the payload. To accomplish this, the intermediate device would need to decrypt the packet, modify it, and encrypt it again. However, doing so would violate the very principle on which such enhanced security is based:  only the source and destination hosts should be privy to the data sent between them. Even if this anomaly were allowed, the overhead incurred would cause an unacceptable degradation in performance in even the fastest firewall devices. For the situations where protocols such as Kerberos or IPSec are used, it is required to use routing firewalls. This routing is not indiscriminate, like the default router behavior, instead the security rules need to be clearly defined to allow such routing of traffic between interfaces to occur, thus creating “screened network” or “protected network”.  It should be noted that the current Microsoft implementation of IPSec does work with either configuration.

Internet Data Center Firewall Overview

The application and management requirements for the Internet Data Center architecture dictate that the servers placed in the DMZ network be multi-homed. For this reason, a set of firewalls is placed both in front of and behind the Web and application servers.  This creates a DMZ network which provides greater protection to the servers that are in the internal network. Finally, to support the requirement for a secure VPN access, a set of redundant firewalls is deployed.. This means that firewalls are placed in three areas in the Internet Data Center architecture, as shown in Figure 1. The first firewall, placed in front of the Internet-facing servers, is referred to as the perimeter or Internet firewall. The next firewall is installed behind the Internet-facing servers and is referred to as the internal firewall. The third firewall, known as the VPN firewall, is used to provide the VPN access and is installed on the data/management network.

The perimeter firewall and switch create the demilitarized zone, or DMZ VLAN, and provide greater protection by controlling the traffic that comes in from the Internet and the traffic between servers in the DMZ VLAN. The internal firewall inspects traffic between the servers in the DMZ and the infrastructure and back-end systems. The VPN firewall manages the remote communications requirements for both the remote management of the IDC and for applications required for Web site development. A fully redundant firewall solution is implemented for the architecture to ensure high availability. The following figure shows the Internet Data Center firewall implementation.

Figure 1. Firewall placement in the Internet Data Center architecture

Each of the three firewalls is described in detail in this chapter, with the final section describing options for achieving high availability.

Microsoft Internet Security Acceleration (ISA) Server or firewall solutions from other vendors can be used for any of the firewalls in the Internet Data Center architecture. To aid in the selection process, the following table describes which firewall features are required or recommended by each of the three firewall types.

Feature\Firewall	Perimeter	Internal	VPN
Packet Filtering	Must have	Must have	Must have
Proxy	Desired for enhanced security. Can provide reverse caching (ISA).	May cause problems with protocols embedding source/destination into packet payload. IPSec/Kerberos.	Not required, since no traffic should traverse except VPN.
Circuit-level	Nice to have. May be required depending on application requirements.	May cause problems with protocols embedding source/destination into packet payload. IPSec/Kerberos.	Not Required.
SPI	Must have.	Must have.	Must have.
NAT/PAT	Desired for enhanced security. Required for server publishing (ISA).	May cause problems with protocols embedding source/destination into packet payload. IPSec/Kerberos.	Must have. IPSec/L2TP will not work.

Table 1. Firewall feature requirements by  firewall type

To demonstrate the flexibility of the Internet Data Center architecture, the Internet Data Center lab used ISA Server for the Perimeter and VPN firewalls and a third-party hardware product for the Internal firewall. ISA Server was chosen because of its increased understanding of the protocols such as HTTP. The advent of web services will emphasize this type of firewall functionality moving forward as most communication will happen over well known protocols such as HTTP. Today any firewall solution used in the Internet Data Center must support at least the following filtering methods or layers: packet filtering, stateful inspection, and application-level filtering, though more intelligent protocol inspection is recommended. Further details of how these layers are implemented in ISA Server are given later in this chapter.

Basic TCP/IP Flow

This section describes how TCP/IP packages its information, to show how firewalls handle traffic securely. Packet filtering is based on information in the TCP/IP packets. The following figure shows a simple breakdown of an IP packet with its  three key sections: the IP Header, the TCP or UDP header, and the actual contents of the packet. (Whether T CP or UDP is used depends on the application-level protocol: HTTP, for example, uses TCP.) The IP header contains the IP addresses of the source, which is the sender, and the destination, which is the receiver. The TCP or UDP header contains the source port of the sender and the destination port of the receiver, in addition to other information, such as sequence numbers, acknowledgement numbers, and the conversation state. The destination TCP or UDP ports define the locations for delivery of the data on the server when the packet reaches its destination. The source port is the port from which the sender sends the packet and is also the port that the destination server responds to in a conversation. The destination port is the port from which the destination server listens and responds to sender requests.

Figure 2. IP Packet structure

It is important to appreciate the communication flow of a TCP/IP conversation when configuring the firewall. When a browser, for example, sends an HTTP request to a Web server, the request contains the identity of the client computer, the source IP address, and the source port that the request went out on. This is also the port from which the client will receive a response from the Web server. The source port for a client of this type is typically a value greater than 1024 (that is, not a part of the well-known range of TCP ports). In addition, the client request contains the destination IP address and destination port of the Web server, in this case port 80, the standard HTTP port.

ISA Server Filtering Methods

ISA Server supports three layers of filtering for comprehensive security: packet filtering, stateful inspection, and application-level filtering. By default, ISA Server blocks all inbound traffic on its external interface and does not allow any traffic through unless rules are created to allow it. The following sections describe the three different layers of filtering that ISA Server supports.

Packet Filtering

Packet filtering is the process of statically opening certain ICMP, TCP, or UDP ports on the firewall’s external interface and determining where to route them internally. In the Internet Data Center architecture, packet filters are implemented if an application, such as DNS, is installed directly on the ISA Server computer. If an additional network segment is created on the ISA Server computer and DNS is placed there, a filter is created that allows all inbound UDP port 53 (DNS query) traffic through to the ISA Server computer itself. A filter might also assist with troubleshooting the ISA Server computer. By default, ISA Server does not respond to ping queries on its external interface. A packet filter would need to be created on the ISA Server computer for it to respond to a ping request. The main TCP/IP attributes used in implementing filtering rules are: 

·         Source IP addresses

·         Destination IP addresses

·         IP protocol

·         Source TCP and UDP ports 

·         Destination TCP and UDP ports 

·         The interface where the packet arrives

·         The interface to which the packet must be delivered

Stateful Inspection Filtering

Stateful inspection is the process of inspecting packets as they reach the firewall and maintaining the state of the connection by allowing or disallowing packets to pass based on the access policy. To further understand how state is maintained, the following figure shows how a conversation between a client and a server takes place through the ISA Server computer. In this scenario, Web Publishing has been configured on the ISA Server computer to support redirecting external Internet requests on port 80 to the internal IIS server.

Figure 3. Sample conversation through ISA Server

This is the flow of the conversation:

1.       The Internet client initiates an HTTP request to the Web server and sends an IP packet with the source and destination address and ports.

2.       The ISA Server computer receives the request for the Web server.

3.       ISA Server then modifies the packet, replacing the source address and port with its own internal address, and changes the destination IP address to the address of the real IIS server.

4.       ISA Server adds the source and destination ports and addresses into its own table to keep track of the conversation.

5.       ISA Server sends the modified packet to the internal IIS server.

6.       The IIS server responds to the request by using ISA Server as the destination address and TCP Port 5300.

7.       ISA Server receives the packet from the IIS server and looks in its table for 5300, which maps to the Internet client.

8.       ISA Server then modifies the packet and replaces the IIS server’s source IP address and port with its own source IP and port.

9.       ISA Server then changes the destination IP address and TCP port to that of the Internet client.

10.   The Internet client listens for a response on TCP port 5100.

In addition to maintaining the TCP or UDP conversation based on IP addresses and ports, ISA Server also checks the TCP flags, the sequence and acknowledgement numbers within the TCP header fields for TCP conversations. The flags represent the state of the conversation, whether it is the beginning of a conversation (SYN), the middle of a conversation (ACK), or the end of the conversation (FIN). If any of the flags are out of sequence, ISA Server blocks the connection. The sequence and acknowledgement fields provide the information to ensure that the next packet received in the conversation is the correct one. Once again any request that does not fit the state of the conversation is blocked.

Application Layer Filtering

ISA Server is also an application-level proxy that is able to read data within packets for a particular application and perform an action based on a rule set. In addition, ISA Server comes with pre-defined application filters that inspect each packet and block, redirect, or modify the data within the packet. For instance, Web-routing rules can be implemented that tell the ISA Server computer to redirect an HTTP request to a certain internal IIS server, based on the URL in the packet. Another example is the DNS intrusion-detection filter. This filter blocks packets that are not valid DNS requests, or that fit common types of DNS attack. Application filtering can be invoked on ISA Server when Web Publishing or Server Publishing is configured.

Microsoft ISA Server 2000 as used in the Internet Data Center environment provides two key Internet functions: firewall-based security (as described earlier in this chapter) and Web-caching services. The Web cache stores frequently accessed pages, which improves network performance and user-response times. Both functions can be implemented on the same server or separated onto dedicated firewall and caching servers.

For the perimeter ISA Server computers, the Network Load Balancing Service is used to configure load balancing on the external interfaces from the Internet Web Publishing IIS servers benefit from this configuration, in which the virtual IP address can be used. The perimeter ISA Server computers also use a configuration called Server Publishing to support applications other than IIS, such as external DNS or SMTP servers. The DNS servers are configured as round-robin DNS to provide redundancy for these application services.

Two ISA Server computers are deployed on the perimeter network in the Internet Data Center architecture to provide stateful-inspection firewall functionality and transparent application proxy and caching. When ISA Server is deployed in the perimeter network, all inbound Internet traffic is analyzed and processed according to a set of rules within a highly scalable and fault-tolerant solution. Web Publishing is implemented for the IIS servers to support HTTP and HTTPS traffic. Server Publishing is implemented to support external DNS traffic. The following sections discuss the Internet Data Center implementation for both Web Publishing and Server Publishing solutions in the perimeter network.

ISA Server Configuration

Both ISA Server computers are configured in stand-alone mode. This configuration means that additional servers are not required if your implementation of the Internet Data Center architecture supports multiple domains. The configuration of both servers differs only slightly—the main difference is in the Server Publishing rules, because the external IP addresses are different. (See "Server Publishing" later in this chapter for more details). In stand-alone mode, the policy is local to the server and cannot be shared across multiple ISA Server computers. The policy is stored in the registry of the local server. Changes must be made on both ISA Server computers independently. These steps can be simplified as each policy element can be scripted using the Microsoft Visual Basic® development system or Microsoft JScript® development software to quickly test out or duplicate a new configuration.

Each ISA Server computer is configured for integrated mode to support both firewall and caching architectures. Reverse caching provides better response times to Internet clients and reduces network traffic.

Hardware Requirements

The following hardware requirements are recommended for the perimeter ISA Server computers in a high-end solution. Each ISA Server computer that is deployed in the perimeter manages the firewall rules, implements reverse caching for Internet clients, and offloads Secure Sockets Layer (SSL) from the IIS servers. Based on the ISA Server computer’s role, a high-end server should at least meet the following minimum requirements:  

·         2 processors

·         2 gigabytes (GB) RAM

·         1 set of mirrored drives to support the operating system and caching or a second set of mirrored drives to support only caching for improved performance

·         Multiple 100-MB Full Duplex Ethernet cards (based on network configuration)  

Service Packs and Hot Fixes

Before the ISA Server computers are configured, the latest service pack, plus all important operating system post–Service Pack hot fixes, must be applied to each server and tested.

Note: ISA Server hot fixes must be applied after the ISA Server installation is completed on each server.

Multihomed

All ISA Server computers are multihomed. The external NIC connects directly to the Internet-facing routers, and the internal NICs connect to the internal VLAN allowing ISA Server to contact the servers in the DMZ with private addresses. (See Figure 4.) Multiple VLANs are created in the DMZ, with ISA Server internal NICs and any Server Publishing servers, such as external DNS servers, all grouped on the same VLAN 21. The IIS server farms are on VLAN 22 and VLAN 23.

Figure 4. ISA Server multihoming and VLAN configuration

Note: For clarity the redundant nature of all network connections has been left out of the figures in this chapter.

Static Routes

In the Internet Data Center environment, the Internet-facing NICs are assigned the default gateway of the Internet-facing router. The internal NIC for each ISA Server computer requires persistent static routes. A static route is created for VLAN 22 and VLAN 23. After these routes are implemented, both ISA Server computers can ping the servers in the other VLANs. The gateway used for the ISA Server computer’s internal addressing is the router component of the switch, defined for each VLAN. The gateway for VLAN 21 was set to 192.168.21.253.

LAT Configuration

Before firewall rules can be configured, the ISA Server computer must be able to detect which interface is connected to the public Internet, and which is connected to the private networks, including all private networks that the ISA Server computer needs to communicate with internally. All of this information is maintained in the ISA Server local address table (LAT). The LAT configuration tells the ISA Server computer where all of the internal networks are located. In a dual NIC implementation, when one NIC is designated as private based on the LAT, the other is then assumed to be public. ISA Server can construct the LAT table automatically based on information in the Microsoft Windows® 2000 routing table, or networks can be added manually. In the Internet Data Center architecture, an entry for each VLAN in the previous figure (192.168.21.0, 192.168.22.0, and 192.168.23.0) is added manually.

Web Publishing

Web Publishing allows the perimeter ISA Server computers to impersonate an internal Web server to the outside world. This provides a highly secure mechanism for controlling inbound Web requests. In addition, transparent caching mechanisms of ISA Server can actively cache frequently requested objects, which improves performance and reduces traffic on the DMZ network.

When Web Publishing is implemented, external client requests for Web services are directed via external DNS entries to the external virtual IP address of the load-balanced ISA Server farm. These requests are then processed by ISA Server, based on Web Publishing rules, and are redirected to the appropriate internal Web server farm. These rules consist of policy elements, including the following:

·         Destination Sets. For Web Publishing, a destination set is typically the domain name contained in a URL whose IP address is the external address of the ISA Server computer. Advanced URL redirection can be implemented through the path functionality of destination sets. The perimeter ISA Server array can be configured to publish Web content split across several Web servers or load-balanced Web server farms.

·         Actions. Actions determine how ISA Server processes external client requests for a particular destination. ISA Server can discard the request or redirect the request to an internal Web server. In addition, ISA Server can translate ports when connecting to internal HTTP, SSL, or FTP resources, and pass host header information. ISA Server can redirect these requests according to the IP address or Fully Qualified Domain Name (FQDN).

·         Bridging. ISA Server can redirect HTTP and SSL requests as HTTP, SSL, or FTP requests and can require a secure channel for the published site. Because ISA Server acts as a proxy for published SSL requests, a valid certificate must be installed on the ISA Server computer.

·         Secure Sockets Layer (SSL) Bridging. Because ISA Server offers a true application-proxy solution, special considerations must be made when implementing certificate-based traffic. ISA Server has built-in functionality to support SSL bridging. SSL allows the ISA Server to encrypt and decode a client request and pass on the request to a destination Web server. This requires that appropriate certificates be installed on the computer running ISA Server.

·         Host Header Bridging. When multiple Web sites are published from a single IP address on an internal Web server, the Web Publishing rules on the perimeter ISA Server array can be configured to send original host header information.

·         Client Sets. Addresses of external Internet clients can be configured to allow or deny access to the Web-server farm. When client sets are not implemented for Web Publishing in the Internet Data Center design, all Internet clients have access to the Web-server farms.

Load Balancing Design

Before any Web Publishing rules are created, the ISA Server computers and the IIS Web servers are configured for load balancing. Network Load Balancing is installed and configured on the external interface of both ISA Server perimeter servers to provide a redundant solution. In addition, the internal IIS servers are grouped into two different Network Load Balancing clusters, each of which is assigned an internal virtual IP address. For more information on the Network Load Balancing implementation in the Internet Data Center architecture, see "Network Load Balancing Design" in Chapter 2, "Network Infrastructure Design."   

High availability is maintained throughout the web publishing design using a combination of network load balancing on the ISA Servers and internal web servers in addition to the way that ISA Server redirects traffic to multiple load balanced IIS Server farms. A host entry is added to each ISA server’s host file using a host name of “iiscluster” and assigning the two internal IIS cluster virtual IP addresses to the host name as follows:

192.168.22.20       iiscluster

192.168.23.21       iiscluster   

A web publishing rule is created to look for the URL *.northwindtraders.com and is configured to redirect the request to the host name iiscluster. Since there are two IP addresses assigned to this host name, ISA Server will apply a random number algorithm to select one of the IP addresses assigned to iiscluster and redirect the external request to the internal IIS Cluster farm assigned to that address that was chosen. ISA Server will apply the random number algorithm on each external request that is processed with this specific web publishing rule.  Additional web publishing rules were created to allow administrators to be able to specifically route a web request from the internet to each internal IIS web farm by using the public virtual IP address assigned the ISA Servers within the URL. The following figure shows this configuration:

Figure 5. ISA Server load-balancing configuration

There is no added benefit for implementing DNS round robin for web publishing multiple IIS cluster farms in which they all participate within the same web site since each ISA server can manage balancing requests to each IIS cluster by using a host file.

Controlling Incoming Requests

Incoming Web requests are configured by setting up listeners on the external network interface of the ISA Server computers. The listener tells the ISA Server which external IP addresses to monitor and accept incoming HTTP and HTTPS traffic. Each load-balanced ISA Server computer is configured to use individual IP addresses, effectively listening on port 80 for each IP address defined in the incoming Web request dialog box. Both ISA Server computers are configured to detect incoming requests on 208.217.208.182 and 208.217.208.183. Any inbound requests on port 80 for any of these IP addresses are processed according to Web Publishing rules, routing rules and IP packet filter rules. If these listeners are not defined, ISA Server does not process any external Web requests.

SSL Configuration

SSL bridging provides a secure, fully redundant, and load-balanced SSL connection between Internet clients and the internal IIS server farms. Bridging means that a client establishes an SSL connection to the ISA Server computer, and then the ISA Server computer can either establish a new SSL connection to the internal Web servers, redirect the client request using HTTP to the Web server, or redirect using FTP. In the Internet Data Center architecture, the perimeter ISA Server computers are configured to redirect the SSL request to the internal IIS server farms by using HTTP (see Figure 6).

This configuration allows the following:

·         The overhead of SSL can be offloaded from the IIS servers to the ISA Server computers. Based on the performance requirements, the SSL processing can also be offloaded from the server CPU by installing hardware accelerator cards.

·         The payload packets can be examined by the ISA Server computers to check for any vulnerable attacks before the packets are delivered to the IIS servers.

·         SSL can work correctly with Network Load Balancing. The IIS servers are configured as Network Load Balancing clusters and are then set for single affinity. This allows incoming SSL requests to always go to the same internal IIS server. If this were not the case, every request could be load balanced to a different server.  This would add additional overhead in re-establishing an SSL connection each time. Single affinity checks only the source IP address. Because the ISA Server computer is performing Network Address Translation (NAT), the source IP will always be the ISA Server computer’s internal IP address, and all requests on the ISA Server computer will always go to the same internal IIS server.

Figure 6. SSL configuration

To support SSL traffic on the ISA Server computers, the computers are configured to detect SSL requests and a certificate is installed on each server. Each Web Publishing rule is updated to bridge the incoming SSL packet by using HTTP to the internal IIS server farm. The certificate that is installed uses a Trusted Root Certificate Authority (CA) that all clients trust. The common name of the certificate should match both the incoming request sent by the Internet client and the name used in the destination set.

Note: Some sites may want to support SSL traffic through ISA Server directly to the internal SSL server. This can be supported by implementing Server Publishing.

Reverse Caching

Another benefit that the perimeter ISA Server computers provide for the Internet site is the ability to cache the static content of the internal IIS servers. This transparent caching mechanism is called reverse caching. By using ISA Server caching features along with incoming Web requests, ISA Server can impersonate an internal Web server to the outside world and fulfill client requests for Web content from its cache. This reverse-caching solution provides better response times to Internet clients and decreases the traffic on the DMZ network.

The Web Proxy service of ISA Server keeps a cache of objects and attempts to fulfill Web requests from the cache. Much of the content in the cache is stored in memory, using a lazy-write mechanism to write the cache contents to disk. This provides increased performance to the external client and has the added security benefit of reducing the amount of traffic that traverses the DMZ. For additional performance, the cache solution can be configured on a different disk than that used for the ISA Server executables.

For the Internet Data Center architecture, each instance of ISA Server is installed in stand-alone mode, with each server maintaining its own cache for incoming requests. You can view the contents of each ISA Server cache by using the cachedir.exe utility from the Support Tools directory on the ISA Server compact disc.

Server Publishing

The Internet Data Center solution requires Internet services, such as DNS. Depending on the application requirements for the Web site, additional services, such as SMTP e-mail and FTP, may also be required. To support these additional applications in the DMZ, Server Publishing rules are implemented on the perimeter ISA Server computers. Server Publishing enables applications that are behind the ISA Server computers to be published to the Internet. Internet clients reference the internal server by sending the request to the ISA Server computer's external IP address.

ISA Server listens for the protocol and port that has been configured in the Server Publishing rule. When a request comes in that matches the rule, ISA Server redirects the IP packet to the internal server. For instance, you can create a Server Publishing rule for an internal DNS server that will tell ISA Server to listen on its external interface for UDP port 53 (DNS query) and to redirect the request to the internal DNS server's private address, 192.168.21.50. Before ISA Server redirects the request, application filters, such as the DNS filter, can be invoked so that ISA Server can examine the contents of the data in the packet and determine if it is suspicious and, therefore, reject the packet before the internal server receives it.

IP Configuration

Server Publishing is configured slightly differently from Web Publishing in the following ways:

·         The TCP/IP packets are handled differently from ISA Server when Server Publishing rules are used. When a request comes in from an Internet client, the source IP and source port that are contained in the original IP packet are not replaced by the ISA Server computer and are included in the IP packet that is redirected to the internal server. Using Web Publishing rules, ISA Server replaces the Internet client source IP and port with the ISA Server computer’s internal IP address and a new port number.

·         Network Load Balancing cannot be implemented for Server Publishing. (Currently, either a hardware load balance solution or a third-party software load-balance solution must be implemented in order to successfully load balance server publishing today). The Network Load Balancing configuration that is implemented for Web Publishing using the external virtual IP addresses cannot be used for Server Publishing. Instead, the dedicated external IP addresses on each ISA Server computer are used for Server Publishing.

For these reasons, the published internal server’s IP configuration will be different from the IIS server's IP configuration. In the Internet Data Center design, all published servers are placed on the same VLAN 21 as the ISA Server computers, and the default gateway for half of the application servers are configured to point to one of the ISA Server computers. The rest point to the second ISA Server computer, as shown in Figure 7.

Figure 7. IP configuration for server publishing

Each pair of application servers is split across each ISA Server for redundancy in support of round-robin DNS. Each application server has two registered IP addresses in DNS, which are the dedicated IP addresses assigned to the external interface of each ISA Server computer (208.217.184.180 and 208.217.184.181). Internet clients reference these addresses to access these services. The virtual IP addresses assigned for the load-balancing ISA Server computers are used for the Web Publishing rules. A session that flows through the ISA Server computers to the internal server must be returned through the same ISA Server computer; otherwise, a firewall rule would be broken. This is why the published servers point to ISA Server as their default gateway. For the IIS servers, ISA Server replaces the external source IP address with its own internal address, so that the internal IIS servers can easily respond back to the same ISA Server computer.

Secure NAT Clients for Server Publishing

Secure NAT clients are simple to implement because they do not require that any additional software be loaded on the internal servers. One requirement for secure NAT is that the internal server must always respond to the ISA Server computer that redirected a request to it. For example, if a request comes from the Internet to ISA Server and ISA Server determines that the request needs to be redirected to an internal IIS server, the IIS server must respond through the same ISA Server computer that the request came from. This is not a problem for Web Publishing, because ISA Server performs NAT by changing the source IP address of the IP packet to its own internal address before it sends the redirected request to the internal IIS server. When the IIS server sees the request, it responds with the internal ISA Server address as the destination address in the IP packet. As long as the internal server IP settings are correctly configured and have the correct default gateway to allow the internal IIS server to respond to the ISA Server computer, the communication will be successful.

For reasons that were discussed earlier, it is important that the internal servers that are Server Published, such as DNS servers, have their default gateway configured to point to the ISA Sever that has publishing rules destined for that internal DNS server. Otherwise, the response from DNS will fail if traffic does not flow back through the same firewall that the request came through.

Securing the Perimeter ISA Server Firewalls

The ISA Server computers are the first in line to have direct contact with the Internet and should be appropriately secured. This process is often referred to as “server hardening”. A security template was created in order to automate applying security to both ISA Servers. This template performs the following:

·         Remove the Admin directory shares

·         Disable unnecessary services

·         Restrict anonymous access

·         Enforce complex passwords

·         Configure the audit logs

Before security is implemented, the ISA Server computer should be completely backed up. Then the template can be applied to ISA by using the secedit command with the /config option from the command prompt. After the ISA Server computers are secure, each one should be rebooted multiple times and thoroughly tested.

This section describes the general design requirements for the internal firewall in the Internet Data Center architecture. We then discuss the specific requirements when Microsoft ISA Server is used in this role.

Basic Requirements

The internal firewall provides added protection for the servers that belong in the internal VLANs, such as the infrastructure and data/management VLANs. If one of the servers in the DMZ VLAN is compromised, the attacker would need to get through the internal firewall in order to do more damage. In addition, NetBIOS is required on the internal interface of the servers on VLAN 11 and the internal firewall protects the internal network servers by not allowing NetBIOS ports 137, 138, and 139 through its interface.

A redundant firewall solution that is highly available should be implemented for the internal firewall design.

Traffic Requirements

Specific TCP and UDP ports are required for communication between the servers in the DMZ network and the servers in the internal network. All servers in the DMZ network are member servers of the Internet Data Center domain. The domain controllers for this domain are located in the internal network. Additionally, management agents can be installed on the front-end servers. These agents require the ability to forward packets to centralized internal management servers. Application servers such as IIS will also need to communicate to internal servers running SQL Server and possibly to application servers such as BizTalk Server. The following table lists the traffic requirements between the servers in the DMZ and the servers that are located in the internal VLANs. This is the configuration the internal firewall is designed to support.

Protocol Definition	Port	Protocol	Notes
Management (App Manager Agent)	9979 9998 9999 +RPC	TCP	Required if servers in the front-end Web have the App Manager Agent installed and they forward to an internal management server.
Management (Ops Manager Agent)	1270	TCP	Required if servers in the front-end Web have the Operations Manager Agent installed and are forwarding information to the internal management servers.
Management (Application Center)	4243 4244	TCP	Required if an Application Center server is used to manage the content of each Web farm.
Management (Terminal Services)	3389	TCP	Allow administrators from management VPN network to access Terminal Services on all servers in the front-end Web.
Application (SQL Server)	1433	TCP	All IIS servers have DNS entries that point to the virtual SQL Server clusters in VLAN 12.
Application (Message Queuing)	1801	TCP	All IIS computers have Message Queuing installed and forward to internal the Message Queuing cluster server in VLAN 13.
Infrastructure (Domain – Kerberos)	88	UDP	DMZ servers that are members of the internal domain.
Infrastructure (Domain – NTP)	123	UDP	DMZ servers that are members of the internal domain.
Infrastructure (Domain – RPC Endpoint Mapper)	135	TCP	DMZ servers that are members of the internal domain.
Infrastructure (Domain – LDAP)	389	TCP UDP	DMZ servers that are members of the internal domain.
Infrastructure (Domain – SMB Direct Host)	445	TCP	DMZ servers that are members of the internal domain.
Infrastructure (Domain – NTDS)	1026	TCP	DMZ servers that are members of the internal domain.

Table 2. Traffic requirements between DMZ and internal VLAN servers

Windows 2000 RPC Port Configuration

Within the Internet Data Center environment, support for DCOM/RPC traffic may be required from servers in the DMZ to servers in the internal network. By default, Windows 2000 DCOM/RPC uses Port 135 (RPC Endpoint Mapper) to negotiate a port above 1023 to use for DCOM/RPC traffic. When a client needs to communicate with a server, and a well-known TCP port is not defined for the server application, the client formulates a request to the server over port 135 to find out which TCP/UDP port the application is listening on. To identify the application to the server, the client may specify the universally unique identifier (UUID) of the application. The server responds back to the client with the actual port to use to initiate a conversation with the internal application. The client then makes another call to the same server, but this time uses the application port that the application is listening on to initiate a conversation.

These application ports can change each time the server is rebooted, which makes it more difficult to configure the firewall to support this type of traffic. To make RPC traffic “firewall friendly,” a specific range of ports should be used for this traffic. Doing so allows the firewall to open specific ranges of ports between VLANs. To configure this in Windows 2000, the following entries must be added to the registry:

Key: HKLM\SOFTWARE\Microsoft\RPC\Internet

Named Value: Ports

Type: REG_MULTI_SZ

Setting: Range of port. This can be multiple lines.

4001-4039

9001-9099

Named Value: PortsInternetAvailable

Type: REG_SZ

Setting: Y

Named Value: UseInternetPorts

Type: REG_SZ

Setting: Y

ISA Server Design Requirements

If ISA Server computers are used as the internal firewall solution, Server Publishing rules are configured in order to publish Active Directory™ directory service ports to the DMZ servers. Additional software or hardware load-balancing solutions must be implemented in front of and behind the internal ISA Server computers to provide a fully redundant and highly available solution. This configuration is sometimes referred to as a firewall sandwich.

Network Configuration

The internal ISA firewall network design is a multihomed configuration just like the perimeter ISA firewall design, with the external interface connected to VLAN 11 and the internal interface connected to VLAN 15. Static routes were created on the internal interface to VLAN 12 and VLAN 13, using 192.168.15.253 as the default gateway. Traffic from the DMZ servers on VLAN 11 can only be proxy through the ISA server to the internal servers on VLAN 12 and VLAN 13.

Publishing Domain Traffic Through ISA

ISA must be configured to listen for the TCP and UDP ports that are used for communication to the domain controllers and to publish them on its external interface on VLAN 11. In order to Server Publish the active directory ports on ISA Server, all of the TCP and UDP ports used for authentication, such as Kerberos and LDAP,  must first be defined in the protocol-definition area of the ISA Server. A protocol definition defines the Port Number, IP Protocol used (TCP or UDP), and Direction (Inbound or Outbound for TCP – Send Only, Receive Only, Send and Receive, Receive and Send for UDP). Once a protocol definition is created, it can be used in packet filters, protocol rules, and Server Publishing rules. These definitions are input to the server publishing rules.

Once all of the protocol definitions are created for the active directory, the ports can be Server Published on ISA’s external interface. Server publishing rules map incoming requests to the appropriate internal servers behind the ISA firewall. ISA listens on its external interface for incoming requests on behalf of the internal server and then creates a new session between itself and the internal server that is managing the session between the client (DMZ Servers) and the internal server (the domain controllers).

Disabling NetBIOS

In order to support domain traffic to and from the domain controllers in the Infrastructure VLAN, the Server Message Block port (TCP Port 445) must be one of the ports that is Server Published on ISA Server and redirected to the internal domain controllers. In order for ISA Server to listen for TCP 445 on its external interface, this port must be completely disabled on the computer that is running ISA Server. The only way to completely disable NetBIOS and SMB on these computers is to disable the NetBIOS device driver.

DNS Design

The Internet Data Center leverages a secure DNS design called “Split/Split DNS.” This design is discussed in the DNS Design section of Chapter 2, “Network Infrastructure Design.” Just like the base architecture Split DNS design, this DNS architecture consists of external DNS servers, Advertisers and Resolvers, that provide name resolution to the Internet clients and internal DNS servers that service only the internal name space.

A Split/Split DNS design has to be used when ISA Server is used as the internal firewall. This is because it is not possible to use Server Publishing to manage the DNS traffic from the servers in the DMZ to the internal DNS services running on the domain controllers that are located on the Infrastructure VLAN. The reason for this is that the IP addresses that are returned from the internal DNS servers cannot be routed through the internal firewalls because ISA Server proxies the requests.

In order to provide name resolution to the servers in the DMZ, the DNS zone files that are located on the internal DNS servers are copied to the external DNS Resolver servers located in the DMZ (see Figure 8), and then the zone files are modified. Placing the internal zone file on the external DNS Resolver is secure from Internet threat, because the DNS Resolver servers are configured not to accept queries from the internet. The host records in the zone file are changed to point to the IP Addresses defined on the internal ISA Server firewall VLAN 11 interface. The DMZ servers' DNS settings are configured to point to the DNS Resolver servers (192.168.11.16, 192.168.11.17) on VLAN 11 in order to resolve names for the internal servers that are behind the ISA Server firewall.

Note: During the deployment phase, there is no internal firewall implemented yet so all servers created in the nwtraders.com domain will have their IP addresses registered to the internal DNS servers (AD01 and AD02). After the deployment phase and ISA server has been implemented as the internal firewall, any server in the DMZ that is joined to the nwtraders.com domain will need to have Host and PTR records added to both DNS01 and DNS02 as well as AD01 and AD02. Dynamic updates are not supported since the internal DNS servers (AD01 and AD02) are not published through ISA.

Figure 8. Split/Split DNS configuration

Note: For clarity in the diagram the VLANs are shown connecting to separate multi-layer switches. In reality all VLANs are managed on a single switch with a second switch configured as a redundant partner.

A virtual private network (VPN) is a way of using a public infrastructure, such as the Internet, to carry a private encrypted point-to-point connection or tunnel. Packets are encapsulated with a wrapper or header that includes routing information. Windows 2000 supports both the common Layer 2 tunneling protocols: PPTP (Point-to-Point Tunneling Protocol) and L2TP (Layer 2 Tunneling Protocol). In the Internet Data Center design, the VPN servers are used to provide access for remote management.

Two VPN servers are deployed for redundancy and high availability. ISA Server is installed on both VPN servers to provide robust packet filtering, stateful packet inspection, and intrusion detection to better secure the VPN traffic. The steps for configuring the VPN servers with ISA Server are as follows:

1.       Configure the IP network settings.

2.       Configure load balancing

3.       Install ISA Server

4.       Configure the VPN network

5.       Implement certificates

IP Addresses

Both VPN servers are multihomed. Their internal interface connects to VLAN 12, with each server assigned an internal static IP address, and their external interfaces connect to the Internet-facing router. A public dedicated IP address was assigned to each VPN server and a public virtual IP address was assigned to both VPN servers Internet facing interface when Network Load Balancing was configured.

Figure 9. Configuring ISA Server for VPN

In this configuration the default gateway is configured on both VPN servers to point to the Internet-facing router in order to allow the VPN servers to respond to any Internet client. Static routes are created on the internal interfaces of both VPN servers. Adding routes to VLAN 11 and VLAN 13 (192.168.11.0 and 192.168.13.0) allows remote administrators to connect to the servers that are not on VLAN 12.

ISA Server Configuration

Both ISA Server and VPN servers are configured for stand-alone mode and are placed in firewall mode only. The LAT is configured for the three private networks 192.168.13.0, 192.168.12.0, and 192.168.11.0. From the LAT, ISA Server can differentiate Internet traffic from internal traffic.

ISA VPN Wizard

It is very simple to configure ISA Server to support client VPN traffic through PPTP and L2TP by using the built-in ISA VPN Wizard. The wizard offers the following three options for VPN configuration:

·         Local ISA Server virtual private network

·         Remote ISA Server virtual private network

·         ISA Server virtual private network

The “ISA Virtual Private Network” option is selected to allow roaming users to connect to the VPN server. After it is selected, ISA Server immediately configures the VPN settings by configuring packet filtering to allow PPTP and L2TP traffic through. During the configuration, ISA Server starts Routing and Remote Access Service (RRAS), if it has not already been started, and changes the service dependency so that RRAS must depend on ISA Server before it can start. The reason for this dependency is that both ISA Server and RRAS implement packet filtering. However, only one of these services can own this functionality on a given server. This dependency designates ISA Server as the owner. After the configuration is completed, you must manually change a setting within the ISA Server configuration to allow PPTP traffic through the firewall.

Packet Filters

Four packet filters that are created in the ISA Server configuration support both PPTP and L2TP traffic. These filters are applied to the ISA Server computer external interface. By default, the ISA wizard will configure these filters to permit PPTP and L2TP traffic through the dedicated IP address assigned to ISA’s internet facing interface. These filters must be manually changed from the dedicated IP address to the clustered or virtual IP address created by Network Load Balancing. This is the address that all of the VPN users will have configured in their clients. Since the L2TP protocol is not supported in this release, the two L2TP packet filters that are automatically created by the ISA Server configuration wizard should be either removed or disabled.

The following table lists the filters that the ISA VPN Wizard creates:

Packet Filter	IP Protocol	Direction	Port
Allow L2TP protocol IKE packets	UDP	Both	500
Allow L2TP protocol packets	UDP	Both	1701
Allow PPTP protocol packets (client)	TCP	Inbound	1723
Allow PPTP protocol packets (server)	TCP	Outbound	1723

Table 3. Filters generated by the ISA VPN wizard

RRAS Configuration

After the ISA Server VPN server has been configured, two additional steps need to be performed on each RRAS server. First, the IP address pool must be defined. These addresses are assigned to each new VPN client that comes through the VPN server. This setting can be configured by either using DHCP or statically assigning the addresses. Since there is no DHCP server in the Internet Data Center architecture, static addresses are assigned on each server with different IP ranges so that there are no conflicts. The first VPN server is configured for static addresses 192.168.12.200 through 192.168.12.209, and the second VPN server is configured for static address assignments 192.168.12.210 through 192.168.12.219.

The second change made to the RRAS server is the number of simultaneous connections that are supported for each protocol (PPTP and L2TP). By default, five connections are configured for both PPTP and L2TP on each server. Depending on the usage of the VPN connections in your implementation, these values may need to be modified. In the Internet Data Center Architecture, L2TP connections were removed from both servers and the number of PPTP connections were changed to support ten simultaneous users.

VPN Protocols

When designing the VPN solution, you can choose between the two main VPN protocols, PPTP and L2TP. The Internet Data Center design supports only PPTP connectivity with Extensible Authentication Protocol (EAP) authentication. A system designer might choose to use PPTP instead of L2TP because it can be used through NAT firewalls. Internet Data Center administrators may be remotely managing the site from a corporate laptop, or possibly a home computer, both of which should be protected behind a firewall (either corporate or personal). If any of these perform NAT on the connection, L2TP will be unusable.

Note: This is not a limitation of the firewall devices or of L2TP, but of the fact that IPSec which is used to encrypt L2TP traffic cannot be used through NAT. This is the case with any vendor firewall or IPSec implementation.

PPTP can be as secure as L2TP when 128-bit encryption and EAP are used with certificates or smart cards for authentication. PPTP with 128-bit encryption can still be made secure without EAP by using long, complex passwords with MS-CHAPV2. This can allow remote management to be performed from clients that do not support EAP, such as Microsoft Windows NT® version 4.0 or Windows 98 operating systems using the latest Dial Up Networking client.

The Internet Data Center design uses PPTP with EAP authentication through certificates as the preferred VPN option, because this gives the best mix of security and flexibility for this design.

Note: An even more secure solution is to use EAP authentication with smart cards, as opposed to the registry-based certificates solution. This option was not chosen for the Internet Data Center architecture, because smart-card readers are still not prevalent in the workplace or at home.

Certificate Services

A certificate server is required to support EAP authentication using certificates, so an internal certificate server was implemented. This solution was chosen to allow the internal administrators to control certificate revocation, certificate-expiration timeframes, and certificate backups. If these features are not important in your design you could chose to use a certificate obtained from a public third-party issuer.

The Internet Data Center certificate server design is being used only to support VPN authentication .The certificate-server deployment architecture for this scenario is not intended to be used as an architecture for a more wide-scale corporate public key infrastructure (PKI) deployment. If certificate services had been required to support more complex scenarios, such as corporate employee usage, or business-to-business (B2B) scenarios, the certificate services would be deployed differently. Since that is not required, though, a very simple architecture is implemented to minimize management overhead.

Because the certificate server will be backed up regularly and certificates will rarely be requested from it (due to the small number of administrators for the site), the low availability needs for this server do not warrant a redundant failover architecture for this service. An enterprise CA is implemented on one of the domain controllers. Additionally, the IIS runs on this domain controller to support Web-based certificate enrollment by users and workstations.

This server’s data and system state get backed up nightly to tape in order to ensure certificate backup, and would take a few hours to restore in the event of a failure.

The Web-based certificate enrollment tool is running on the certificate server and is used to service certificate requests from client workstations and users. Both of the VPN servers have the CA root certificate and a machine certificate installed, which is accomplished by creating an organizational unit for the VPN servers in Active Directory. Group Policy is then applied to this organizational unit, which automatically enrolls the machines contained within it for machine certificates.

RRAS Server Configuration

Because the Extensible Authentication Protocol (EAP) is used as the authentication mechanism for PPTP, it is configured as the only accepted authentication mechanism and all others are disabled. Therefore, users are not able to connect to the VPN servers by using user names and passwords. This increases the security of the VPN solution.

This does mean that the administrators of the system are required to request the CA’s root certificate and a user certificate while physically in the office. If administrators request these certificates from a company-owned laptop, they will be able to use the laptop to connect to the site. If they wish to administer the system from home they will need to export certificates to a floppy disk, which they then take home and install on their home computer. If the certificate is to be exported to a floppy disk, the Mark keys as exportable option must be chosen when the certificate is requested, or the certificate with its accompanying private key will not be exportable from the computer on which it was requested.

After the certificates are imported on the administrator’s home workstation, the certificate or key on the floppy disk should be erased, and the floppy destroyed. Optimally, for the highest level of security, the certificate or key would be stored on a smart card; however, because smart card readers are not yet prevalent in the marketplace, their use has not been required in the architecture. The certificate required for EAP authentication is a user certificate, which must be placed in the user personal certificate store on the Windows 2000 workstation.

Remote-Access Policy

The Remote-Access Policy is configured to accept EAP for authentication only at the strongest encryption level allowed. The strongest option allows connections to use only IPSec Triple DES or MPPE 128-bit encryption. This setting requires the 128-bit encryption pack to be installed on both clients and servers.

Remote-Access Logging

The Remote Authentication Dial-In User Service (RADIUS) was not used in the architecture because centralized accounting and management for VPN connections were not required to support remote access for the administrators. Accounting requests (such as accounting start or stop) and authentication requests, such as Access-Accept or Access-Reject, are logged on to the RRAS server. The RRAS server has a feature to log status periodically, such as interim accounting requests. This logging feature is not enabled because it can result in high-volume logs. A custom location, away from the default location, is specified for the log file, so that security can be tightened on the directory.

As explained earlier in this document, the IDC architecture requires that firewall solutions be highly available and fault tolerant. This goal can be met using a combination of Microsoft ISA Server and the Network Load Balancing Service, or Microsoft ISA Server together with a third-party clustering solution. The following sections describe the design issues that relate to the ISA Server/ Network Load Balancing Service solution.

Using the Network Load Balancing Service with ISA Server

The Network Load Balancing Service can provide both fault-tolerance and horizontal scaling for the computers running ISA Server. The Network Load Balancing Service has port rules that can be configured to perform two functions:

·         They specify affinity and load handling behavior on a port-by-port basis.

·         They provide a level of security in that these rules are processed prior to packets reaching TCP/IP stack on the server.

By default the Network Load Balancing Service has one rule configured. This rule defines the following settings for the corresponding parameters:

Parameter	Setting
Port Range	1-65535
Affinity	Single
Filter Mode	Multiple hosts
Load	Equal
Protocols	Both

Table 4. Default Network Load Balancing Service rule configuration

Port Rules

The default port rule is removed because no affinity should be used on stateless protocols or applications to achieve the best load-balancing configuration. Instead, the following rules are set on the servers running ISA Server:

Rule	Start	End	Protocol	Mode	Load	Affinity
1	0	442	Both	Multiple	Equal	None
2	443	443	TCP	Multiple	Equal	Single
3	444	65535	Both	Multiple	Equal	None

Table 5. ISA Server rules

This version of the architecture provides three services to the Internet:

·         HTTP. This is a stateless protocol, unless a Web application’s session state is maintained on the Web server. This is highly discouraged for Web farms; application-session state should be maintained centrally in a database or some other centrally accessible storage mechanism.

·         HTTPS. This is a session-oriented protocol.

·         DNS. This is published through the ISA Server computers and therefore uses the dedicated IP address of the ISA Server computers, bypassing any Network Load Balancing port configuration.

For HTTPS, a session is established every time a client from the Internet connects with a different firewall that is publishing out the Web farm. If no affinity is used for HTTPS, the client may have to re-create a session every time it tries to connect to the Web farm. This is unacceptable.

Therefore, port 443 is configured for single affinity. This ensures that once a client establishes an SSL session with one firewall, that session will remain intact until the client is finished or the session times out.

Class C affinity is another option for load balancing. This option is similar to single affinity except that this option guarantees that clients with IP addresses within the same Class C range of addresses will be load balanced to the same firewall.

Third-Party Solutions

It is also possible to provide a high-availability solution using third-party solutions that provides dynamic load balancing across multiple ISA Server firewalls. For more details on these solutions, see the following :
http://www.microsoft.com/isaserver/partners/highavailability.asp

The Internet Data Center firewall design provides a secure, fault-tolerant environment. This chapter describes firewall operations, common design issues, and the types of firewall used in the IDC architecture. Detail is provided on the use of Microsoft ISA Server as both a firewall and Web cache. High availability firewall solutions using ISA Server, together with the Network Load Balancing Service or third-party products, are also described.

More Information

For more information about Microsoft Internet Security and Acceleration Server, refer to the ISA Server Web site at:
http://www.microsoft.com/isaserver