Configure ISA 2004 as a Network Services Segment Perimeter Firewall

[LEFT][CODE]http://www.isaserver.org/tutorials/Configure-ISA-2004-Network-Services-Segment-Perimeter-Firewall-Part1.html[/CODE]

[B][SIZE=3][B]Part 1: Perimeter Network Design Principles and Considerations[/B][/SIZE][/B]


The ISA firewall can act in a number of roles: a front-end edge firewall that sits in front of the entire company, as a back-end firewall located behind another edge firewall that might be an ISA firewall or another type of firewall, or a perimeter network firewall that walls off critical network servers and services from the rest of the network. It’s this latter configuration we’ll focus on in this article.
In spite of eye-catching headlines about the death of the DMZ or the imminent demise of network security zones, the fact is that we who live in the trenches still need to live with the current reality, where network perimeters need to be defined to provide access controls on hosts connecting to other hosts belonging to a different security zone. And while Network Access Protection (NAP – expected to be implemented in Longhorn/Vista) and IPSec-based domain isolation hold a lot of promises, there are and will be significant technological hurdles that have to be met before those methodologies will be applicable to widespread use.
Instead of proclaiming the death of the DMZ, security experts should be making the clarion call for increased [I]perimeterization[/I]. You’ll go a long way at improving your network’s security position by grouping hosts into different security zones and putting firewalls and other network security devices between those zones that enable strong access controls on communications between those zones.
In this article we’ll examine the requirements and procedures involved with creating a network services segment separated from the rest of the corporate network by an ISA firewall. You can put an ISA firewall in front of the network services located on the services segment to help protect those critical network services from being adversely affected by outbreaks that take place on other network segments.
The key concept here is that only required communications are allowed to and from the network services segment; all other communications are blocked. In addition to limiting communications only to those hosts and protocols that are required for access, we will leverage the ISA firewall’s advanced stateful packet and application layer inspection mechanisms to help secure the communications allowed to the network services segment.
[B]Network Services Segment Configuration Options[/B]

As with all network security devices, and especially for network firewalls, there is no such thing as “one size fits all” when it comes to configuration. There is no replacement for understanding how your firewall works, and how to configure it to meet your organization’s specific requirements.
There are two scenarios we should look at before proceeding with a step by step example for configuring a network services segment behind an ISA firewall. These scenarios are:

[LIST][*]A LAN router separates the ISA firewall from the rest of the corporate network[*]No LAN router separates the ISA firewall from the rest of the corporate network[/LIST]
While there are variations on the second theme, out discussions of these two scenarios will hopefully make clear what your configuration options are when you don’t have a LAN router on your network.
[B]Scenario 1: LAN Router between ISA Firewall and Corporate Network[/B]

A high level view of scenario 1 appears in the figure below. In this scenario, there is a LAN router between the ISA firewall and the rest of the network. There is a route relationship between all internal networks located behind the edge ISA firewall. NAT is used only for communications to the Internet.
In this scenario, hosts on the corporate network in front of the network services perimeter ISA firewall use a default gateway that is the local address of the LAN router. The LAN router is configured with a route of last resort (which allows it to access the Internet) that is the internal address on the edge ISA firewall. The LAN router is configured with a routing table entry that provides a route to the network ID located behind the network services perimeter network ISA firewall.
When a user makes a request to a server on the network services segment located behind the network services perimeter ISA firewall, the request is forwarded to the client’s default gateway address, since the connection is to a non-local (remote) network. The packet is then forwarded based on the routing table entry on the LAN router to the IP address on the external interface of the network services perimeter ISA firewall, and then the network services perimeter ISA firewall routes the request to the server on the network services segment.
The request path is seen with the black arrows. The response path is seen in the Red arrows. The server on the services segment sends the response to its default gateway, which is the IP address on the internal interface of the network services segment perimeter ISA firewall. The response is forwarded directly to the client making the request since the ISA firewall has knowledge of all network IDs to which it is directly connected. The response is [I]not[/I] forwarded to the LAN router and then back to the client. Note that the request and response paths are not the same.
[INDENT] [IMG]http://www.isaserver.org/img/upl/Image11128931482091.JPG[/IMG]
[B]Figure 1[/B][/INDENT]The figure below shows the request and response paths for connections made to the Internet. Notice in this case the request and response paths are the same.
[INDENT] [IMG]http://www.isaserver.org/img/upl/Image21128931482091.JPG[/IMG]
[B]Figure 2[/B][/INDENT][B]Scenario 2: No LAN Routers[/B]

Now let’s look at scenario 2, where there is no router between the ISA firewall and the rest of the network. In this case, the clients on the corporate network use the internal interface of the edge ISA firewall as their default gateway address. The edge ISA firewall is configured with a routing table entry informing the edge ISA firewall of the correct route to network ID [B]10.0.0.0/24[/B]. The ISA firewall forwards the connection to the IP address on the external interface of the network services perimeter ISA firewall, which then routes the connection to the server on the network services segment.
The response from the server on the network services segment is forwarded to the server’s default gateway address, which is the IP address on the internal interface of the network services perimeter ISA firewall, which in turn forwards the response directly to the client machine that made the request. Notice that the request and response paths are not the same. This scenario works because the ISA firewall is handling traffic that it has knowledge of and is not dealing with response traffic to connections it is not aware of. This will be made clear in the next figure.
[INDENT] [IMG]http://www.isaserver.org/img/upl/Image31128931482091.JPG[/IMG]
[B]Figure 3[/B]
[B] [CENTER]

[URL="http://www.amazon.com/exec/obidos/ASIN/1931836191/ref%3Dnosim/searchbyisbn/wwwshindernet-20/104-5191863-1267954"]
[/URL][/CENTER]
[/B][/INDENT][B]ISA Firewall Stateful Packet Inspection and Request/Response Paths[/B]

The figure below shows a scenario where a system on the network services segment needs to [I]initiate[/I] a connection to a host on the corporate network. A network management server on the network services segment makes a connection to a workstation on the corporate network in front of the network services perimeter ISA firewall.
The connection is first sent to the network services perimeter ISA firewall’s internal interface, as this is the default gateway of the network management server. The connection is then sent directly to the workstation, because the ISA firewall has knowledge of all networks to which is it directly connected. That is to say, the ISA firewall can do an ARP broadcast to get the MAC address of the workstation and send the request directly to that workstation.
A problem arises when the workstation tries to respond to the management server on the network services segment. Since the destination IP address of the management server is on a network [I]remote[/I] from the workstation’s network ID, the workstation sends the response to its default gateway, which is the internal interface of the edge ISA firewall. The response traffic is denied by the ISA firewall because the client is sending a SYN-ACK message back to the management server, but the ISA firewall never “saw” the SYN message from the management server to the workstation. Since the ISA firewall is a stateful packet inspection firewall, it drops the SYN-ACK because it isn’t associated with an preceding SYN.
[INDENT] [IMG]http://www.isaserver.org/img/upl/Image41128932145982.JPG[/IMG]
[B]Figure 4[/B][/INDENT]There are several ways you can deal with this issue:

[LIST][*]Make sure that no servers on the network services segment behind the perimeter ISA firewall ever need to create new outbound TCP connections to hosts on the corporate network in front of the network services perimeter ISA firewall. This means that not only can you not place servers making outbound connections through the network services perimeter ISA firewall, but also cannot use protocols where the clients make primary connections to the servers on the network services segment and require secondary connections from the servers on the network services segment.[*]Put a LAN router between the ISA firewall and the rest of the corporate network[*]Put a LAN router between the network services segment perimeter ISA firewall and the rest of the network[*]Create routing table entries on the hosts located on the corporate network in front of the network services perimeter ISA firewall so that they know the gateway address to reach the network services segment, which in this case would be the IP address on the external interface of the network services perimeter ISA firewall[*]Use multiple NICs on the ISA firewall and place the network services segment on an ISA firewall Network associated with one of the NICs. This avoids the routing and network with a Network issue[/LIST]
Most enterprise networks will have LAN routers in place, so it’s easy for these organizations to create the appropriate routing table entries to support this scenario. For small organizations that do not have LAN routers in place, you can get complete support for connections to and from the network services segment by automating routing table entries on the corporate network hosts located in front of the network services segment perimeter ISA firewall. You could use a log on script to enter these routing table entries on the clients using the [B]route add –p[/B] command.
[B]Multiple Departmental Networks/Security Zones Connected to a Backbone Network[/B]

Note that these issues are specific for the network within a Network configuration and when there are clients systems that are “on subnet” with an ISA firewall that must be reached from a host on a remote subnet that is part of the [I]same ISA firewall Network[/I]. This is not a problem when you have backbone network configured and clients and servers are all behind ISA firewalls.
For example, consider the network in the figure below. In this scenario we do not run into similar problems because there are no host systems on the backbone network, and therefore no host systems that are “on-subnet” of the edge ISA firewall’s internal interface. All ISA firewalls contain routing table entries directing them to the external interface of the appropriate ISA firewall to reach the appropriate network ID(s) located behind any specific ISA firewall. Hosts behind each of the ISA firewalls use the internal interface of their local ISA firewall as their default gateway, and the routing table entries on the ISA firewalls route the connection to the correct ISA firewall’s external interface.
Note that we are assuming a Route relationship between all ISA firewall networks in this scenario, although a mix of Route and NAT relationships will work too, and can potentially simplify the routing table entries, since segments that use a NAT relationship do not require routing table entries on the ISA firewall to reach the addresses behind the NAT – the responder only needs to reach the IP address on the external interface of the ISA firewall sending the connection, and in a backbone network scenario, all the external interfaces are likely on the same network ID.
[INDENT] [IMG]http://www.isaserver.org/img/upl/Image51128932145982.JPG[/IMG]
[B]Figure 5[/B][/INDENT]Note that in order for this configuration to work most efficiently, each ISA firewall requires the appropriate routing table entries. However, you could get around this requirement if each ISA firewall used the edge ISA firewall as its default gateway, and the edge ISA firewall contained the appropriate routing table entries. This solution could potentially work, but performance would be abysmal because the edge ISA firewall would be routing connections between all network IDs on the corporate network.
[B]Example Network and Perimeter Network Design for this Article Series[/B]

In this article series we will use the sample network seen in the figure below. The default gateway for all servers on the network services segment will be the IP address on the internal interface of the network services perimeter ISA firewall. The default gateway for all hosts on the corporate network containing client systems is the IP address on the internal interface of the edge ISA firewall. Client systems are configured with a routing table entry that forwards connections to network ID [B]10.0.0.0/24[/B] to the IP address on the external interface of the network services perimeter ISA firewall.
[INDENT] [IMG]http://www.isaserver.org/img/upl/Image61128932145982.JPG[/IMG]
[B]Figure 6[/B][/INDENT]There is a Windows 2000 file server and an Exchange 2003 server located on the network services segment. The Exchange Server is also a domain controller, DNS server, WINS server, DHCP server, certificate server and RADIUS server. We will create access rules that enable connections to all the network services on the Exchange Server and also to file shares on the File server. The File server will host the Firewall client installation files so that we can avoid allowing file sharing protocols to any of the ISA firewall’s Local Host Network. The network services perimeter ISA firewall is already joined to the domain.
In the articles that follow this one you will perform the following procedures:

[LIST][*]Create an ISA firewall Network representing the corporate network on the network services perimeter ISA firewall[*]Create a Network Rule on the network services perimeter ISA firewall that sets a Route relationship between the corporate network and the network services network[*]Create an intradomain communications Access Rule on the network services perimeter ISA firewall that allows corporate network hosts access to the DC on the services segment for intradomain communications and a DNS Server Publishing Rule that enables the DNS application layer inspection filter[*]Create Access Rules Controlling Outbound Access from the Network Services Segment on Perimeter ISA Firewall[*]Create network services Access Rules on the network services perimeter ISA firewall enabling clients access to network services (OWA, Outlook MAPI, SMTP, POP3, IMAP4, file shares)[*]Create a routing table entry on the edge ISA firewall providing a path to the network services segment network ID[*]the front-end ISA Firewall to the domain[*]Create a routing table entry on the network clients (only required if there are no LAN routers installed) providing route information to reach the network services segment network ID[*]Join the network clients to the domain[*]Create a wpad entry in DNS to enable autodiscovery for Firewall and Web proxy clients[*]Configure the Firewall client settings on the edge ISA firewall (including Web proxy client configuration)[*]Install the Firewall client share on the network services segment file server[*]Install the Firewall client on the network clients[*]Connect the corporate network clients to resources on the network services segment and the Internet[/LIST]
[CENTER] [/CENTER]
[B]Summary[/B]

In this article we reviewed issues and concepts related to using the ISA firewall as a network services segment perimeter firewall. We discussed issues related to routing connections to remote network IDs and how these issues interact with the ISA firewall’s stateful packet inspection feature. Several scenarios were discussed and routing options available in each scenario. We finished off the article by describing the sample network that will be used in the remainder of this article series. Subsequent articles in this series will go over the procedures required to complete the solution and in depth discussions on the rationale behind the configuration decisions made at each juncture.
[/LEFT]

[LEFT][LEFT][CODE]http://www.isaserver.org/tutorials/Configure-ISA-2004-Network-Services-Segment-Perimeter-Firewall-Part2.html[/CODE][/LEFT]
[B][SIZE=3]
[/SIZE][/B] [B][B][SIZE=3]Part 2: Configuring the Network Service Perimeter ISA Firewall[/SIZE][/B][/B]


In the first part of this multipart article series on configuring a network services segment using a perimeter ISA firewall, we discussed concepts and issues in perimeter network design and issues related to the ISA firewall’s stateful packet inspection mechanisms. We also went over the sample network design used in this article series. In this, part 2 of the article series, we’ll move our attention to the network services segment perimeter ISA firewall.
In this, part 2 of the article series, we’ll move our attention to the network services segment perimeter ISA firewall. We’ll do the following in this article:

[LIST][*]Create the ISA Firewall Network Representing the Corporate Network on the Network Services Perimeter ISA firewall[*]Create the Network Rule on the Network Services Perimeter ISA Firewall Setting a Route Relationship between the Corporate Network and the Network Services Segment[*]Create an Intradomain Communications Access Rule on the Network Services Perimeter ISA Firewall and a DNS Server Publishing Rule[*]Create Access Rules Controlling Outbound Access from the Network Services Segment on Perimeter ISA Firewall[/LIST]
As a reminder, the figure below provides a high level view of the sample network used in this article series.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0021129537432727.JPG[/IMG]
[B]Figure A[/B][/INDENT][B]Create the ISA Firewall Network Representing the Corporate Network on the Network Services Perimeter ISA firewall[/B]

One of the most prevalent misconceptions regarding ISA firewall Networks and how the ISA firewall sees the network world is how the ISA firewall deals with the default External Network. Let’s set the record straight: the default External Network on the ISA firewall is defined as any IP address that isn’t part of any other ISA firewall Network configured on the ISA firewall.
What this means is you can configure any collection of IP addresses that [I]aren’t part of another ISA firewall Network[/I] to be part of a custom ISA firewall Network. This includes the IP address(es) bound to the external interface of the ISA firewall (although the addresses on the external interface of the ISA firewall will always belong to the Local Host Network).
This allows us to create a custom ISA firewall Network that includes the IP addresses used on the corporate network that lies between the edge ISA firewall and the network services perimeter ISA firewall. These addresses [I]do not[/I] need to be part of the default External Network, even though the corporate network is on the same network ID as the [I]external interface[/I] of the ISA firewall. The term “external interface” only means that it’s the interface with the default gateway configured on it, which typically is the closest to the Internet.
[INDENT] [B]NOTE:
[/B]While the term external interface is used to denote the NIC that has the default gateway configured on it, the fact is that you can configure an ISA firewall that has no default gateway. This ISA firewall won’t be able to access the Internet and hosts serviced that that ISA firewall won’t be able to access the Internet, but it does illustrate that an ISA firewall does not require an external interface.[/INDENT]The value of making the corporate network between the edge ISA firewall and the network services perimeter ISA firewall a separate ISA firewall Network is that you can control the routing relationship between that Network and any other Network defined on the ISA firewall. In the example network used in this article, configuring a custom corporate ISA firewall Network will enable us to create a route relationship between the default Internal Network behind the back-end ISA firewall and the corporate network between the edge ISA firewall and the network services ISA perimeter ISA firewall. We can also create Access Rules controlling traffic moving to and from any ISA firewall Network.
[B]Create the Corpnet ISA Firewall Network[/B]
Perform the following steps on the network services perimeter ISA firewall to create the Corpnet ISA firewall Network:

[LIST=1][*]In the ISA firewall console, expand the server name and then expand the [B]Configuration[/B] node. Click the [B]Networks[/B] node.[*]On the [B]Networks[/B] node, click the [B]Networks[/B] tab in the details pane. Click the [B]Tasks[/B] tab in the Task Pane and then click the [B]Create a New Network[/B] link.[*]On the [B]Welcome to the New Network Wizard[/B] page, enter a name for the Network in the [B]Network name[/B] text box. In this example we’ll name the Network [B]Corpnet[/B]. Click [B]Next[/B].[*]On the [B]Network Type[/B] page, select the [B]Perimeter Network[/B] option and click [B]Next[/B].[*]On the [B]Network Address[/B] page, click the [B]Add[/B] button.[*]In the [B]IP Address Range Properties[/B] dialog box, enter the [B]Starting address [/B]and [B]Ending Address[/B] for the Corpnet ISA firewall Network. In this example we’ll enter [B]10.0.1.0[/B] for the [B]Starting Address[/B] and [B]10.01.255[/B] for the [B]Ending Address[/B]. Note that you don’t have to include the entire network ID; you can include only the addresses that are actually in use on that network, or you can get even more granular and include only those addresses that you want to have a route relationship with the default Internet Network behind the network service perimeter ISA firewall so that you can later create another ISA firewall Network representing other addresses on the corporate network that you want to create a NAT relationship with. Click [B]OK[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0041129537432727.jpg[/IMG]
[B]Figure 1[/B] [/INDENT]
[LIST=1][*] Click [B]Next[/B] on the [B]Network Addresses[/B] page.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0061129537432742.jpg[/IMG]
[B]Figure 2[/B][/INDENT]
[LIST=1][*]Click [B]Finish[/B] on the [B]Completing the New Network Wizard[/B] page.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0081129537432742.jpg[/IMG]
[B]Figure 3[/B][/INDENT][B]Create the Network Rule on the Network Services Perimeter ISA Firewall Setting a Route Relationship between the Corporate Network and the Network Services Segment[/B]

In the scenario discussed in this article, the hosts the corporate network are members of a domain that has its domain controllers located behind the network services perimeter ISA firewall.
An Access Rule must be created that allows hosts on the corporate network to communicate with the DCs on the network services segment. Intradomain communications require that you have a [I]Route[/I] relationship between the source and destination networks. For this reason, we will create a Network Rule that sets a Route relationship between the corporate network and the default Internal Network located behind the network services perimeter ISA firewall.
It’s important to note that although there will be a route relationship between the network services perimeter ISA firewall’s default Internal Network and the Corpnet Network, there will still be a NAT relationship between the network services perimeter ISA firewall’s default Internal Network and the Internet. This is fully supported (and required), since private addresses are used on all networks behind the edge ISA firewall.
[B]Create the Network Rule Defining a Route Relationship between the Corpnet ISA Firewall Network and the Default Internal Network[/B]
Perform the following steps to create the Network Rule creating a route relationship between the Corpnet Network and the default Internal Network behind the network services perimeter ISA firewall:

[LIST=1][*]In the ISA firewall console, expand the server name and then expand the [B]Configuration[/B] node in the left pane of the console. Click the [B]Networks[/B] node.[*]On the [B]Networks[/B] node, click the [B]Network Rules[/B] tab in the details pane of the console, then click the [B]Create a New Network Rule[/B] link in the [B]Tasks[/B] tab of the Task Pane.[*]On the [B]Welcome to the New Network Rule Wizard[/B] page, enter a name for the rule in the [B]Network rule name[/B] text box. In this example we’ll name the rule [B]Corpnet – Internal [/B](the default Internal Network behind the network services perimeter ISA firewall represents the network services segment). Click [B]Next[/B].[*]On the [B]Network Traffic Sources[/B] page, click the [B]Add[/B] button.[*]In the [B]Add Network Entities[/B] dialog box, click the [B]Networks[/B] folder and then double click the [B]Corpnet[/B] Network. Click [B]Close[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0101129538087867.jpg[/IMG]
[B]Figure 4[/B][/INDENT]
[LIST=1][*] Click [B]Next[/B] on the [B]Network Traffic Sources[/B] page.[*] Click [B]Add[/B] on the [B]Network Traffic Destinations[/B] page.[*] Click the [B]Networks[/B] folder and then double click the [B]Internal[/B] entry. Click [B]Close[/B].[*] On the [B]Network Relationship[/B] page, select the [B]Route[/B] option and click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0121129538087914.jpg[/IMG]
[B]Figure 5[/B][/INDENT]
[LIST=1][*] Click [B]Finish[/B] on the [B]Completing the New Network Rule Wizard[/B] page.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0141129538087914.jpg[/IMG]
[B]Figure 6[/B][/INDENT][B]Create an Intradomain Communications Access Rule on the Network Services Perimeter ISA Firewall and a DNS Server Publishing Rule [/B]

Multiple protocols are required to allow intradomain communications between hosts on the corporate network and domain controllers on the corporate network. Table 1 provides the details of this Access Rule. Table 2 provides details of the DNS Server Publishing Rule.
[B]Table 1: Access Rule allowing intradomain communications between the DMZ host and the DC on the default Internal Network behind the back-end ISA firewall[/B]
[INDENT]
[B]Name[/B]
Intradomain Corpnet -- Internal
[B]Action[/B]
Allow
[B]Protocols[/B]
Microsoft CIFS (TCP)
Microsoft CIFS (UDP)
Kerberos-Adm(UDP)
Kerberos-Sec(TCP)
Kerberos-Sec(UDP)
LDAP
LDAP (UDP)
LDAP GC (Global Catalog)
RPC (all interfaces)
NTP (UDP)
Ping
[B]From[/B]
Corpnet
[B]To[/B]
Domain Controller
[B]Users[/B]
All
[B]Schedule[/B]
Always
[B]Content Types[/B]
All content types[/INDENT][B]Table 2: DNS Server Publishing Rule [/B]
[INDENT]
[B]Name[/B]
Publish Domain DNS
[B]Action[/B]
Allow
[B]Protocols[/B]
DNS Server
[B]Listener[/B]
Corpnet
[B]To[/B]
10.0.0.2
[B]Schedule[/B]
Always[/INDENT]Note that we are using an Access Rule instead of a publishing rule to allow access from the Corpnet ISA firewall Network and the network services segment network. The reason for this is that we have a route relationship between these two Networks. Since we have a route relationship, we have no need or ability to hide the addresses of the servers on the network services segment.
You might be concerned that won’t be able to leverage the ISA firewall’s deep application layer inspection application filters when using Access Rules, but the fact is that you [I]can[/I] benefit from the application layer filters for most protocols. If you check the protocol definitions associated with the Protocol Definitions associated application filters, you’ll see that both inbound and outbound Protocol Definitions for the protocols have the application layer inspection filters bound to them.
Unfortunately, the DNS filter is not one of the filters that you can use for both inbound and outbound access stateful application layer inspection. Even though you can bind the DNS application layer inspection filter to the outbound DNS Protocol Definition, the filter will have no effect.
You can test this yourself by binding the DNS application layer inspection filter to the outbound DNS protocol and then create an Access Rule from the Corpnet to the network services segment network using this DNS Protocol Definition. Then block DNS zone transfers in the [B]Enable Intrusion Detection and DNS Attack Detection[/B] dialog box. After creating the Access Rule and configuring the DNS intrusion detection, try to perform a DNS zone transfer using the [B]nslookup[/B] utility and issuing the [B]ls –d <domain_name.>[/B] command. You’ll find that you can perform the zone transfers. In contrast, if you performed a DNS Server Publishing Rule, the zone transfer will fail because the DNS application layer inspection filter detected the intrusion.
For this reason, we will create two publishing rules: one for DNS communications and another for all other intradomain communications. While we could simplify the configuration by including the DNS protocol in the intradomain communications Access Rule, we would miss out on the added protection provided by the DNS filter.
[B]Create the Intradomain Communications Rule[/B]
Perform the following steps to create the intradomain communications Access Rule on the network services perimeter ISA firewall:

[LIST=1][*]In the ISA firewall console, expand the server name and then click the [B]Firewall Policy[/B] node in the left pane of the console.[*]On the [B]Firewall Policy[/B] node, click the [B]Tasks[/B] tab in the Task Pane and click the [B]Create New Access Rule [/B]link.[*]On the [B]Welcome to the New Access Rule Wizard[/B] page, enter the name of the rule in the [B]Access Rule name[/B] text box. In this example, we’ll name the rule [B]Intradomain Corpnet —Internal[/B] and click [B]Next[/B].[*]Select the [B]Allow[/B] option on the [B]Rule Action[/B] page.[*]On the [B]Protocols[/B] page, select the [B]Selected protocols[/B] option from the [B]This[/B][B] rule applies to[/B] list. Click [B]Add[/B].[*]Click the [B]Add Protocols[/B] folder and then double click the following protocols:
[B]Microsoft CIFS (TCP)
[/B][B]Microsoft CIFS (UDP)
[/B][B]DNS
[/B][B]Kerberos-Adm(UDP)
[/B][B]Kerberos-Sec(TCP)
[/B][B]Kerberos-Sec(UDP)
[/B][B]LDAP
[/B][B]LDAP (UDP)
[/B][B]LDAP GC (Global Catalog)
[/B][B]RPC (all interfaces)
[/B][B]NTP (UDP)
[/B][B]Ping
[/B]Click [B]Close[/B] in the [B]Add Protocols[/B] dialog box.[*]Click [B]Next[/B] on the [B]Protocols[/B] page.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0161129538087930.jpg[/IMG]
[B]Figure 7[/B][/INDENT]
[LIST=1][*]On the [B]Access Rule Sources[/B] page, click the [B]Add [/B]button.[*]In the [B]Add Network Entities[/B] dialog box, double click the [B]Corpnet[/B] entry and then click [B]Close[/B].[*]Click [B]Next[/B] on the [B]Access Rule Sources[/B] page.[*]Click [B]Add[/B] on the [B]Access Rule Destinations[/B] page.[*]In the [B]Add Network Entities[/B] dialog box, click the [B]New[/B] menu and then click [B]Computer[/B].[*]In the [B]New Computer Rule Element[/B] dialog box, enter a name for the domain controller on the Internal Network (the network services segment). In this example we’ll name the Computer Object [B]Domain Controller[/B]. Enter the IP address of the domain controller in the [B]Computer IP Address[/B] text box. Enter an optional [B]Description[/B] if you like. Click [B]OK[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0181129538455836.jpg[/IMG]
[B]Figure 8[/B][/INDENT]
[LIST=1][*] In the [B]Add Network Entities[/B] dialog box, click the [B]Computers[/B] folder and then double click on the [B]Domain Controller[/B] entry. Click [B]Close[/B].[*] Click [B]Next[/B] on the [B]Access Rule Destinations[/B] page.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0201129538455836.jpg[/IMG]
[B]Figure 9[/B][/INDENT]
[LIST=1][*] Accept the default setting, [B]All Users[/B], on the [B]User Sets[/B] page and click [B]Next[/B].[*] Click [B]Finish[/B] on the [B]Completing the New Access Rule Wizard[/B] page.[/LIST]
[B] [CENTER]

[URL="http://www.amazon.com/exec/obidos/ASIN/1931836191/ref%3Dnosim/searchbyisbn/wwwshindernet-20/104-5191863-1267954"]
[/URL][/CENTER]
[/B] [B]Create the DNS Server Publishing Rule [/B]
The next step is to create the DNS Server Publishing Rule. Perform the following steps on the network service perimeter ISA firewall to create the DNS Server Publishing Rule:

[LIST=1][*]In the ISA firewall console, expand the server name and then click the [B]Firewall Policy[/B] node.[*]On the [B]Firewall Policy[/B] node, click the [B]Tasks[/B] tab in the Task Pane and then click the [B]Creae a New Server Publishing Rule[/B] link.[*]On the [B]Welcome to the New Server Publishing Rule Wizard[/B] page, enter a name for the rule in the [B]Server Publishing Rule name[/B] text box. In this example, we’ll name the rule [B]Publish Domain DNS[/B] and click [B]Next[/B].[*]On the [B]Select Server[/B] page, enter the IP address of the DNS server for the domain in the [B]Server IP address[/B] text box. In this example, the domain’s DNS server is located on the domain controller, which is at IP address [B]10.0.0.2[/B]. We enter this IP address into the text box and click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0221129538455867.jpg[/IMG]
[B]Figure 10[/B][/INDENT]
[LIST=1][*]On the [B]Select Protocol[/B] page, select the [B]DNS Server[/B] option from the [B]Selected[/B][B] protocol[/B] list. Click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0241129538723680.jpg[/IMG]
[B]Figure 11[/B][/INDENT]
[LIST=1][*]On the [B]IP Address[/B] page, put a checkmark in the checkbox next to [B]Corpnet[/B] and click [B]Next[/B]. There is an interesting vagary to this setting, which I’ll talk more about at the end of this section.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0261129538723680.jpg[/IMG]
[B]Figure 12[/B][/INDENT]
[LIST=1][*]Click [B]Finish[/B] on the [B]Completing the New Server Publishing Rule Wizard[/B] page.[/LIST]
I mentioned that there is an interesting twist to Server Publishing Rules when you have a route relationship between the source and destination ISA firewall Network. To fully appreciate the situation, let’s first examine what happens when there is a NAT relationship between the published server and the external client.
When there is a NAT relationship between the published server and the external client, the external client reaches the published server [I]using the IP address on the external interface of the ISA firewall configured to listen for incoming connections [/I]for that specific Server Publishing Rule. For example, if there were a NAT relationship between the published DNS server and the Corpnet, then we could choose the IP address [B]10.0.1.2[/B] on the external interface of the network services perimeter ISA firewall as the listening address. Hosts that need to reach the published server would send DNS queries to the IP address used in the Server Publishing Rule listener, [I]not[/I] the actual IP address of published Web server.
In contrast, when there is a route relationship between the source and destination ISA firewall Network, the external client reaches the published DNS server (or any other server [B]except[/B] a Web server published using a Web Publishing Rule) using the [I]actual IP address[/I] of the published server. So, even through we’ve created a DNS Server Publishing Rule that has a listener on the external interface of the network services perimeter ISA firewall, the external clients must use the actual IP address to reach the DNS server, which in this case is [B]10.0.0.2[/B].
[B]Create Access Rules Controlling Outbound Access from the Network Services Segment on Perimeter ISA Firewall[/B]

You must create Access Rules allowing new outbound connections from hosts on the network services segment and any other Network. In most cases, the only outbound connections you’ll want to allow are those that enable access to the Windows update site or the WSUS server on the corporate network. You would also likely want to enable outbound access to public DNS servers, if you’re domain DNS servers are also providing Internet host name resolution.
Exactly what you want allow outbound from the servers on the network services segment is going to be very specific to your own implementation. In our current example, we’re only going to allow outbound DNS from the DNS server and outbound HTTP and HTTPS from all hosts on the network services segment to the Windows Update sites.
[INDENT] [B]NOTE:
[/B]You do not need to create outbound Access Rules from the network services segment to the Corpnet ISA firewall Network to support the inbound access rules from the Corpnet ISA firewall Network to the network services segment network. The ISA firewall is a stateful packet inspection firewall and will automatically allow the responses to requests made from hosts on the Corpnet Network.[/INDENT][B]Create the Access Rule Allowing DNS from the DNS Server to the Internet[/B]
Perform the following steps to create the Access Rule:

[LIST=1][*]At the back-end ISA firewall, in the ISA firewall console expand the name of the server and then click the [B]Firewall Policy[/B] node in the left pane of the console.[*]Click the [B]Create New Access Rule [/B]link on the [B]Tasks[/B] tab in the Task Pane.[*]In the [B]Welcome to the New Access Rule [/B]dialog box, enter a name for the rule in the [B]Access Rule name[/B] text box. In this example we’ll name the rule [B]DNS to External[/B]. Click [B]Next[/B].[*]On the [B]Rule Action[/B] page, select the [B]Allow[/B] option and click [B]Next[/B].[*]On the [B]Protocols[/B] page, select the [B]Selected protocols[/B] option from the [B]This[/B][B] rule applies to[/B] list. Click [B]Add[/B].[*]Click the [B]Common Protocols[/B] folder and then double click the [B]DNS [/B]entry. Click [B]Close[/B].[*]Click [B]Next[/B] on the [B]Protocols [/B]page.[*]On the [B]Access Rule Sources[/B] page, click the [B]Add[/B] button.[*]In the [B]Add Network Entities[/B] dialog box, click the [B]Computers[/B] folder and double click the [B]Domain Controller[/B] entry. Click [B]Close[/B].[*]Click [B]Next[/B] on the [B]Access Rule Sources[/B] page.[*]On the [B]Access Rule Destinations[/B] page, click the [B]Add[/B] button.[*]In the [B]Add Network Entities[/B] dialog box, click the [B]Networks[/B] folder. Double click the [B]External[/B] Network. Click [B]Close[/B].[*]Click [B]Next[/B] on the [B]Access Rule Destinations[/B] page.[*]On the [B]User Sets[/B] page, accept the default entry, [B]All Users[/B], and click [B]Next[/B].[*]Click [B]Finish[/B] on the [B]Completing the New Access Rule Wizard[/B] page.[/LIST]
[B]Create the Access Rule allowing Outbound Windows Update and Microsoft Reporting[/B]
Perform the following steps to create the HTTP/HTTPS Access Rule allowing access to the Windows Update and Reporting Sites:

[LIST=1][*]At the back-end ISA firewall, in the ISA firewall console expand the name of the server and then click the [B]Firewall Policy[/B] node in the left pane of the console.[*]Click the [B]Create New Access Rule [/B]link on the [B]Tasks[/B] tab in the Task Pane.[*]In the [B]Welcome to the New Access Rule [/B]dialog box, enter a name for the rule in the [B]Access Rule name[/B] text box. In this example we’ll name the rule [B]Outbound to WU and MS Reporting .[/B] Click [B]Next[/B].[*]On the [B]Rule Action[/B] page, select the [B]Allow[/B] option and click [B]Next[/B].[*]On the [B]Protocols[/B] page, select the [B]Selected protocols[/B] option from the [B]This[/B][B] rule applies to[/B] list. Click [B]Add[/B].[*]Click the [B]Common Protocols[/B] folder and then double click the [B]HTTP[/B] and [B]HTTPS [/B]entries. Click [B]Close[/B].[*]Click [B]Next[/B] on the [B]Protocols [/B]page.[*]On the [B]Access Rule Sources[/B] page, click the [B]Add[/B] button.[*]In the [B]Add Network Entities[/B] dialog box, click the [B]Networks[/B] folder and double click the [B]Internal[/B]entry. Click [B]Close[/B].[*]Click [B]Next[/B] on the [B]Access Rule Sources[/B] page.[*]On the [B]Access Rule Destinations[/B] page, click the [B]Add[/B] button.[*]In the [B]Add Network Entities[/B] dialog box, click the [B]Domain Name Sets[/B] folder. Double click the [B]Microsoft Error Reporting sites [/B]and [B]System Policy Allowed Sites [/B]entries. Click [B]Close[/B].[*]Click [B]Next[/B] on the [B]Access Rule Destinations[/B] page.[*]On the [B]User Sets[/B] page, accept the default entry, [B]All Users[/B], and click [B]Next[/B].[*]Click [B]Finish[/B] on the [B]Completing the New Access Rule Wizard[/B] page.[*]Click [B]Apply [/B]to save the changes and update the firewall policy.[*]Click [B]OK[/B] in the [B]Apply New Configuration[/B] dialog box.[/LIST]
Your firewall policy should look like the figure below.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0281129538723711.jpg[/IMG]
[B]Figure 13[/B]
[CENTER][/CENTER][/INDENT][CENTER][B][URL="http://www.amazon.com/exec/obidos/ASIN/1931836191/ref%3Dnosim/searchbyisbn/wwwshindernet-20/104-5191863-1267954"]
[/URL][/B][/CENTER]
[B]Summary[/B]

In this part 2 of our article series on creating network services segment protected by a perimeter ISA firewall, we began the process by configuring the network services perimeter ISA firewall. Procedures included creating the ISA firewall Network defining the corporate network, creating a Network Rule that sets a route relationship between the network service segment and corporate network, and created a number of Access Rules and a Server Publishing Rule to allow communications inbound and outbound to and from the network services segment. In the next part of this article series we will complete the firewall policy on the network services perimeter ISA firewall.




[/LEFT]

[LEFT][CODE]http://www.isaserver.org/tutorials/Configure-ISA-2004-Network-Services-Segment-Perimeter-Firewall-Part3.html[/CODE]
[B][SIZE=3]
[/SIZE][/B][B][B][SIZE=3]Part 3: Creating Services Access Rules and Joining Machines to the Domainand Joining Machines to the Domain[/SIZE][/B][/B]


[B]Create the Network Services Access Rules Enabling Corpnet Clients Access to Network Services (OWA, SMTP, POP3, IMAP4, File Shares)[/B]

Now we’re ready to create Publishing Rules and Access Rules that allow hosts on both the Corpnet ISA firewall Network and external clients on the Internet to access Exchange Server and File server resources on the network services segment. Hosts on the Corpnet ISA firewall Network will be able to connect to Exchange Server and file server resources by going through the network services segment perimeter ISA firewall. Hosts on the Internet will need to traverse both the edge ISA firewall and the network services segment perimeter ISA firewall. Later we will create the rules on the Edge ISA firewall to enable access to network services perimeter resources.
In this section we will do the following:

[LIST][*]Create an OWA Publishing Rule on the network services perimeter ISA firewall[*]Create SMTP, POP3 and IMAP4 Server Publishing Rules[*]Create an Access Rule allowing access to file shares on the file server[/LIST]
In the scenario discussed in this series on creating network services segments using ISA firewalls, I will assume that you have already deployed your certificate infrastructure and have already requested the appropriate Web site certificates to support SSL/TLS connections to the Exchange Server’s e-mail services.
If you haven’t done this and are not sure how to start, I highly recommend the ISA Server 2004/Exchange Server deployment kit documents I created for Microsoft over at [URL]http://download.microsoft.com/download/1/8/8/188ab94a-4ec5-4746-ac0f-a18177040fbf/isa2004se_exchangekit-rev%201%2005.doc[/URL] (note that this is a single very large document; if you need an individual Word file that applies to your network configuration from one of the chapters in the deployment kit doc, then write to me at [EMAIL="tshinder@isaserver.org"]tshinder@isaserver.org[/EMAIL] and I’ll send you the separate doc).
In the scenario used in this article series, we’ve bound certificates to the OWA Web site, the SMTP site, the POP3 site and the IMAP4 site on the Exchange Server on the network services segment. Table 1 shows the common/subject names on the certificates bound to each site.
[INDENT]
[B]Exchange Server service[/B]
[B]Common/subject name on Web Site Certificate[/B]
OWA
owa.msfirewall.org
SMTP
mail.msfirewall.org
POP3
pop3.msfirewall.org
IMAP4
Imap4.msfirewall.org
[B]Table 1: Common names bound to Exchange Server services
[/B][/INDENT]In the following sections we will create Access Rules, Web Publishing Rules and Server Publishing Rules with the characteristics listed in table 2.
[INDENT] [B] [B]Order[/B]
[B]Name[/B]
[B]Action[/B]
[B]Protocols[/B]
[B]From/Listener[/B]
[B]To[/B]
[B]Condition[/B]
1
Exchange Server IMAPS Server
Allow
IMAPS Server
Corpnet
10.0.0.2
N/A
2
Exchange Server POP3S Server
Allow
POP3S Server
Corpnet
10.0.0.2
N/A
3
Exchange Server SMTP Server
Allow
SMTP Server
Corpnet
10.0.0.2
N/A
4
Exchange Server IMAP4 Server
Allow
IMAP4 Server
Corpnet
10.0.0.2
N/A
5
Exchange Server POP3 Server
Allow
POP3 Server
Corpnet
10.0.0.2
N/A
6
Exchange Server SMTPS Server
Allow
SMTPS Server
Corpnet
10.0.0.2
N/A
7
Publish OWA
Allow
HTTPS
OWA Listener
owa.msfirewall.org
All Authenticated Users
8
Publish DNS
Allow
DNS Server
Corpnet
10.0.0.2

9
DNS to External
Allow
DNS
Domain Controller
External
All Users
10
Outbound WU and MS Reporting
Allow
HTTP
HTTPS
Internal
Microsoft Error Reporting Sites
System Policy Allowed Sites
All Users
11
Intradomain Corpnet – Internal
Allow
Kerberos-Adm (UDP)
Kerberos-Sec (TCP)
Kerberos-Sec (UDP)
LDAP
LDAP (UDP)
LDAP GC (Global Catalog)
Microsoft CIFS (TCP)
Microsoft CIFS (UDP)
NTP (UDP)
Ping
RPC (all interfaces)
Corpnet
Domain Controller
All Users
12
File Server Access
Allow
Microsoft CIFS (TCP)
Microsoft CIFS (UDP)
Corpnet
File Server 1
All Users
Table 2: Resulting Firewall Policy on the network services perimeter ISA firewall[/B][/INDENT]To simplify the configuration, we’ll leverage the ISA firewall’s Mail Server Publishing Wizard to create multiple publishing rules simultaneously.
[B]Create an OWA Publishing Rule on the Network Services Perimeter ISA Firewall[/B]

Perform the following steps on the network services perimeter ISA firewall to create the Web Publishing Rule that publishes the OWA Web site:

[LIST=1][*]In the ISA firewall console, expand the server name and then click the [B]Firewall Policy[/B] node.[*]On the [B]Firewall Policy[/B] node, click the [B]Tasks[/B] tab in the Task Pane and then click the [B]Publish a Mail Server[/B] link.[*]On the [B]Welcome to the New Mail Server Publishing Rule Wizard[/B] page, enter a name for the rule in the [B]Mail Server Publishing Rule name[/B] text box. In this example, we’ll name the rule [B]Publish OWA[/B] and click [B]Next[/B].[*]On the [B]Select Access Type[/B] page, select the [B]Web client access: Outlook Web Access (OWA), Outlook Mobile Access, Exchange Server ActiveSync[/B] option and click [B]Next[/B].[*]On the [B]Select Services[/B] page, select the [B]Outlook Web Access[/B] checkbox and click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0021129820444444.jpg[/IMG]
[B]Figure 1[/B][/INDENT]
[LIST=1][*]On the [B]Bridging Mode[/B] page, select the [B]Secure[/B][B] connection to clients and mail server[/B] option. This enables SSL to SSL bridging. Click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0041129820444460.jpg[/IMG]
[B]Figure 2[/B][/INDENT]
[LIST=1][*]On the [B]Specify the Web Mail Server[/B] page, enter the name on the Web site certificate bound to the OWA Web site. In this example, the name is [B]owa.msfirewall.org[/B]. Keep in mind that the ISA firewall will need to resolve this name to the actual IP address of the OWA site on the network services segment. You can do this with a hosts file entry on the ISA firewall, or setup a split DNS infrastructure.
The split DNS infrastructure might be challenging in this scenario, because as you’ll see later, we would need to create a triple split DNS to support name resolution for the ISA firewall itself, for hosts on the corporate network, and for hosts located on the Internet. While putting together a well-designed split DNS infrastructure is fairly simple, some network admins have misconceptions that it's either insecure or difficult to manage. Both misconceptions are patently incorrect and you should not fall prey to them. We will create the HOSTS file entry on the network services perimeter ISA firewall after we’ve created all the publishing and Access Rules. Click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0061129820444475.jpg[/IMG]
[B]Figure 3[/B][/INDENT]
[LIST=1][*]On the [B]Public Name Details[/B] page, select the [B]This[/B][B] domain name (type below)[/B] in the [B]Accept requests for[/B] list. Enter the common/subject name on the Web site certificate that will be bound to the Web listener for this Web Publishing Rule. In this example, we have exported the Web site certificate bound to the OWA Web site and imported it into the machine certificate store on the ISA firewall. Because this is the same certificate, it has the same common/subject name. Therefore, we enter [B]owa.msfirewall.org[/B] in the [B]Public name[/B] text box. Click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0081129820444491.jpg[/IMG]
[B]Figure 4[/B][/INDENT]
[LIST=1][*]On the [B]Select Web Listener[/B] page, click the [B]New[/B] button.[*]On the [B]Welcome to the New Web Listener Wizard[/B] page, enter a name for the listener in the [B]Web listener name[/B] text box. In this example we’ll name the Web listener [B]OWA Listener[/B]. Click [B]Next[/B].[*]On the [B]IP Addresses[/B] page, put a checkmark in the [B]Corpnet[/B] checkbox and click [B]Next[/B].[*]On the [B]Port Specification[/B] page, remove the checkmark from the [B]Enable HTTP[/B] checkbox and put a checkmark in the [B]Enable SSL [/B]checkbox. Click the [B]Select[/B] button.[*]Select the OWA Web site certificate from the list in the [B]Select Certificate[/B] dialog box and click [B]OK[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0101129821187116.jpg[/IMG]
[B]Figure 5[/B][/INDENT]
[LIST=1][*]Click [B]Next[/B] on the [B]Port Specification[/B] page.[*]Click [B]Finish[/B] on the [B]Completing the New Web Listener[/B] page.[*]On the [B]Select Web Listener[/B] page, click the [B]Edit[/B] button.[*]On the [B]OWA Listener Properties[/B] dialog box, click the [B]Preferences[/B] tab.[*]On the [B]Preferences[/B] tab, click the [B]Authentication[/B] button.[*]In the [B]Authentication[/B] dialog box, remove the checkmark from the [B]Integrated[/B] checkbox. Click [B]OK[/B] in the dialog box informing you that you don’t have any authentication methods configured. Put a checkmark in the [B]OWA Forms-based[/B] checkbox. Put a checkmark in the [B]Require[/B][B] all users to authenticate[/B] checkbox. Click [B]OK[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0121129821187116.jpg[/IMG]
[B]Figure 6[/B][/INDENT]
[LIST=1][*] [B]OK[/B] in the [B]OWA Listener Properties[/B] dialog box.[*] Click [B]Next[/B] on the [B]Select Web Listener[/B] page.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0141129821187147.jpg[/IMG]
[B]Figure 7[/B][/INDENT]
[LIST=1][*] On the [B]User Sets[/B] page, click the [B]All Users[/B] entry and click [B]Remove[/B]. Click the [B]Add [/B]button.[*] In the [B]Add Users[/B] dialog box, double click the [B]All Authenticated Users[/B] entry and click [B]Close[/B].[*] Click [B]Next[/B] on the [B]User Sets[/B] page.[*] Click [B]Finish[/B] on the [B]Completing the New Mail Server Publishing Rule Wizard[/B] page.[/LIST]
Your firewall policy should like that seen in the figure below.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0161129821187163.jpg[/IMG]
[B]Figure 8[/B]
[B] [CENTER]

[URL="http://www.amazon.com/exec/obidos/ASIN/1931836191/ref%3Dnosim/searchbyisbn/wwwshindernet-20/104-5191863-1267954"]
[/URL][/CENTER]
[/B][/INDENT][B]Create SMTP, POP3 and IMAP4 Server Publishing Rules [/B]

The next step is to create the Server Publishing Rules that publish the rest of the Exchange Server services. These include Server Publishing Rules for Secure Exchange RPC, SMTP, POP3 and IMAP4. We have the option to create these rules separately or create them all at once by using the Mail Server Publishing Wizard. We’ll use the latter option to simplify things.
You might notice that we’re not going to create a secure Exchange RPC Server Publishing Rule in this example. The reason for this is related to two factors:

[LIST][*]We’re using a route relationship between the Corpnet ISA firewall Network[*]The intradomain communications Access Rule is configured to allow inbound TCP 135 communications (the RPC (all interfaces) Protocol Definition)[/LIST]
Because we are using a Route relationship instead of a NAT relationship between the source and destination Network, we can’t bind a specific IP address to the listener used in the Server Publishing Rule. When you use a Route relationship, the Server Publishing Rule listens on all addresses bound to the external interface using a feature known internally as [I]port stealing[/I]. Because both the Secure Exchange RPC server Server Publishing Rule and the RPC (all interfaces) component of the intradomain communications Access Rule are listening for similar communications, we end up with a conflict that prevents Outlook MAPI clients from connecting to Directory services.
If there were a NAT relationship between the Corpnet and the network services segment, we could bind multiple IP addresses to the external interface of the network services perimeter ISA firewall. Then we could create two rules: one for Secure Exchange RPC publishing and the other for RPC (all interfaces) and use a different listening address for each of the rules. Machines on the Corpnet ISA firewall Network then connect to Secure Exchange RPC services or RPC (all interfaces) services using the IP address used for their respective rule’s listener. This works because connections are made to the IP addresses on the ISA firewall’s external interface when you have a NAT relationship between the network services segment and the Corpnet ISA firewall Network.
It doesn’t work when there is a Route relationship between the network services segment and the Corpnet ISA firewall Network because hosts on the Corpnet ISA firewall Network connect to the Exchange server [I]using the actual IP address of the Exchange Server[/I]. Since the hosts are connecting to the IP address of the Exchange Server itself and not an IP address on the external interface of the ISA firewall, the ISA firewall’s [I]port stealing[/I] mechanism must listen and intercept RPC communications on [I]all IP address of the external interface[/I]. This breaks the granularity required to allow both a Secure Exchange RPC Server Publishing Rule and a RPC (all interfaces) Access Rule on the same ISA firewall when there is a Route relationship between the source and destination ISA firewall Networks.
You can confirm this by creating both a secure Exchange RPC Server Publishing Rule in the scenario used in this article series. Then attempt to make a connection to the Exchange Server from the full Outlook MAPI client using RPC (don’t use RPC/HTTP, since the inbound connection is HTTP, so the ISA firewall doesn’t see the RPC communications tunneled in the HTTP header). You’ll that the connection seems to establish successfully, but if you open the [B]Connection Status[/B] window in Outlook 2003, you’ll find that the RPC connections are successful only to the Exchange Server’s Mail Services. No connection is established to Directory Services.
[B]Create Server Publishing Rules for POP3, IMAP4 and SMTP[/B]
Perform the following steps to create the Server Publishing Rules on the network services perimeter ISA firewall:

[LIST=1][*]In the ISA firewall console, expand the server name and then click the [B]Firewall Policy[/B] node.[*]On the [B]Firewall Policy[/B] node, click the [B]Tasks[/B] tab on the Task Pane and click the [B]Publish a Mail Server [/B]link.[*]On the [B]Welcome to the New Mail Server Publishing Rule Wizard[/B] page, enter a name for the rule in the [B]Mail Server Publishing Rule name[/B] text box. In this example, we’ll name the rule [B]Exchange Server[/B] and click [B]Next[/B].[*]On the [B]Select Access Type[/B] page, select the [B]Client access: RPC, IMAP, POP3, SMTP[/B] option and click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0181129821187194.jpg[/IMG]
[B]Figure 9[/B][/INDENT]
[LIST=1][*]On the [B]Select Services[/B] page, put a checkmark in each of the checkboxes. This will allow us to connect to the Exchange Server on the network services segment through the network services perimeter ISA firewall for all the services listed on this page (with the exception of the Exchange Server’s NNTP service, we could create a separate rule for that if required). Note the comment on the page regarding the SMTP Message Screener. We will not deploy the message screener in this example, but you might want to consider it in your own deployment. You can install the SMTP Message Screener on the ISA firewall to filter both inbound and outbound mail. Even though the SMTP Message Screener won’t be enabled, the SMTP filter is enabled and will protect SMTP communications moving through the network services perimeter ISA firewall. Click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0201129821187210.jpg[/IMG]
[B]Figure 10[/B][/INDENT]
[LIST=1][*]On the [B]Select Server[/B] page, enter the IP address of the Exchange Server in the [B]Server IP address[/B] text box. In this example, the Exchange Server’s IP address is [B]10.0.0.2[/B], so we enter that value. Click [B]Next[/B].[*]On the [B]IP Addresses[/B] page, put a checkmark in the [B]Corpnet[/B] checkbox. Click [B]Next[/B].[*]Click [B]Finish[/B] on the [B]Completing the New Mail Server Publishing Rule Wizard[/B] page.[/LIST]
Your Firewall Policy should appear similar to that in the figure below. Note that the Mail Server Publishing Rule Wizard added seven new Server Publishing Rules. Click [B]Apply [/B]to save the changes and update the firewall policy. Click [B]OK[/B] in the [B]Apply New Configuration[/B] dialog box.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0221129822567585.jpg[/IMG]
[B]Figure 11[/B][/INDENT][B]Create an Access Rule Allowing Access to File Shares on the File Server[/B]

Now we can create the Access Rule allowing connections to file shares on the file server on the network services segment. We can enable either NetBIOS protocols or Direct Hosting (TCP 445). In this example we’ll enable only Direct Hosting, which is more efficient than NetBIOS protocols.
Perform the following steps to create the Direct Hosting Access Rule:

[LIST=1][*]In the ISA firewall console, expand the server name and then click the [B]Firewall Policy[/B] node.[*]On the [B]Firewall Policy[/B] node, click the [B]Tasks[/B] tab in the Task Pane and then click the [B]Create New Access Rule[/B].[*]On the [B]Welcome to the New Access Rule Wizard[/B] page, enter a name for the rule in the [B]Access Rule name[/B] text box. In this example, we’ll name the rule [B]Publish File Server[/B]. Click [B]Next[/B].[*]Select the [B]Allow[/B] option on the [B]Rule Action[/B] page and click [B]Next[/B].[*]On the [B]Protocols[/B] page, select the [B]Selected protocols[/B] option from the [B]This[/B][B] rule applies to[/B] list and then click [B]Add[/B].[*]In the [B]Add Protocols[/B] dialog box, click the [B]All Protocols[/B] folder and then double click the [B]Microsoft CIFS (TCP)[/B] and [B]Microsoft CIFS (UDP)[/B] protocols. Click [B]Close[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0241129822567616.jpg[/IMG]
[B]Figure 12[/B][/INDENT]
[LIST=1][*] Click [B]Next[/B] on the [B]Protocols[/B] page.[*] Click [B]Add[/B] on the [B]Access Rule Sources[/B] page.[*] In the [B]Add Network Entities[/B] dialog box, click the [B]Networks [/B]folder and then double click the [B]Corpnet[/B] entry. Click [B]Close[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0261129822567631.jpg[/IMG]
[B]Figure 13[/B][/INDENT]
[LIST=1][*] Click [B]Next[/B] on the [B]Access Rule Sources[/B] page.[*] Click [B]Add[/B] on the [B]Access Rule Destinations[/B] page.[*] In the [B]Add Network Entities[/B] dialog box, click the [B]New[/B] menu and then click [B]Computer[/B].[*] In the [B]New Computer Rule Element[/B] dialog box, enter a name for the file server in the [B]Name[/B] text box. In this example, we’ll name it [B]File Server 1[/B]. Enter the IP address of the file server located in the network services segment in the [B]Computer IP Address[/B] text box. Enter an optional description if you like. Click [B]OK[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0281129822567647.jpg[/IMG]
[B]Figure 14[/B][/INDENT]
[LIST=1][*] Click the [B]Computers[/B] folder in the [B]Add Network Entities[/B] dialog box and double click the [B]File Server 1[/B] entry and click [B]Close[/B].[*] Click [B]Next[/B] on the [B]Access Rule Destinations[/B] page.[*] Click [B]Next[/B] on the [B]User Sets[/B] page.[*] Click [B]Finish[/B] on the [B]Completing the New Access Rule Wizard[/B] page.[/LIST]
Your firewall policy should look like that in the figure below.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0301129884313678.jpg[/IMG]
[B]Figure 15[/B]
[B] [CENTER]

[URL="http://www.amazon.com/exec/obidos/ASIN/1931836191/ref%3Dnosim/searchbyisbn/wwwshindernet-20/104-5191863-1267954"]
[/URL][/CENTER]
[/B][/INDENT][B]Summary[/B]

In this article we finished up the configuration of the network services perimeter ISA firewall. We used the Mail Server Publishing Wizard to create a Web Publishing Rule allowing connections to the Exchange Server’s OWA, SMTP, POP3 and IMAP4 services. No Server Publishing Rule was created to allow access to the Exchange Server’s secure RPC services because of an issue related to the intradomain communications rule. In part 4 of this series, we will move our attention to configuring the edge network ISA firewall and hosts on the Corpnet ISA firewall Network.





[/LEFT]

[LEFT][CODE]http://www.isaserver.org/tutorials/Configure-ISA-2004-Network-Services-Segment-Perimeter-Firewall-Part4.html[/CODE]
[B][SIZE=3]
[/SIZE][/B][B][B][SIZE=3]Part 4: Configuring the Edge ISA Firewall[/SIZE][/B][/B]


In the first three parts of this series on configuring a network services segment behind an ISA firewall, we began by going over concepts and considerations in creating perimeter networks. In part 2, we discussed the initial configuration of the network services perimeter ISA firewall. In part 3 we continued configuring the network services perimeter ISA firewall by adding Web Publishing Rules, Server Publishing Rules and Access Rules. In this, part 4 of the series, we’ll move out attention to the edge ISA firewall.
In this, part 4 of the series, we’ll move out attention to the edge ISA firewall. In this article we’ll perform the following procedures on the edge ISA firewall:

[LIST][*]Configure the Default Internal Network and Create a Routing Table Entry on the Edge ISA Firewall[*]Join the Front-end ISA Firewall to the Active Directory Domain[*]Create Access Rules on the Edge ISA Firewall Controlling Outbound Access from Corpnet Hosts and Hosts on the Network Services Segment[*]Create Publishing Rules on the Edge ISA Firewall to Allow Inbound Connections to the Exchange Server Mail Services[/LIST]
As a reminder, the figure below provides a high level view of the sample network used in this article series.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0021130424651341.gif[/IMG]
[B]Figure A[/B][/INDENT][B]Configure the Default Internal Network on the Edge ISA Firewall[/B]

When the edge ISA firewall was installed, it took its definition of the default Internal Network from the routing table on the edge ISA firewall device. The routing table entries indicated to the ISA firewall installer that the addresses [B]10.0.1.0-10.0.1.255[/B] should be included in the definition of its default Internal Network. This is a correct configuration if the only network behind the edge ISA firewall was on network ID 10.0.1.0/24. However, in our scenario this is an incorrect configuration and will cause problems with access controls on connections to and from the network services segment through the edge ISA firewall.
The reason for the problem with the initial settings for the default Internal Network on edge ISA firewall is that there is a Route relationship between the Corpnet ISA firewall Network (which is the edge ISA firewall’s default Internal Network) and the default Internal Network behind the network services segment ISA firewall. Because there is a route relationship, connections from SecureNAT clients located behind the network services perimeter ISA firewall will reach the edge ISA firewall with their original client IP address included as the source address (note that this is not the case with proxied connections by Winsock [Firewall] and Web proxy clients). If we leave the edge ISA firewall’s default Internal Network definition as it is now, then connections from SecureNAT clients located behind the network services perimeter ISA firewall will be detected as spoofed packets.
ISA firewall Networks are used to determine the validity of connections reaching the interface that is the “root” of a particular ISA firewall Network. For the edge ISA firewall, the root of its default Internal Network is the internal interface which is on network ID 10.0.1.0/24. Any connections with a source IP address on that network ID are seen as valid.
However, if a connection with a source IP address that is not part of the edge ISA firewall’s default Internal Network’s definition is made through the interface that is the root of the edge ISA firewall’s default Internal Network (which is the internal interface of the edge ISA firewall), then the connection is dropped as a spoof attempt. The ISA firewall assumes that it’s not possible for an interface to accept a connection from a host on an ISA firewall Network that isn’t the same as that for which the interface is root.
[INDENT] [B]Note:
[/B]I’m using the term “root” to represent a point of exit and departure. The term “root” does not imply that the NIC’s IP address or network ID defines what network IDs or subnets can be placed behind a NIC. You can put contiguous or discontinuous network IDs behind any NIC. The only requirements are that all IP addresses located behind any NIC on the ISA firewall must be included in the ISA firewall Network for which that NIC is “root” and that no other ISA firewall Network includes the same addresses.[/INDENT]We can easily solve this problem by adding the IP addresses included in the network services perimeter ISA firewall’s default Internal Network (which is the network services segment) to the definition of the edge ISA firewall’s default Internal Network definition.
[B]Add IP Addresses of the Network Services Perimeter Segment to the Front-End ISA Firewall’s Default Internal Network[/B]
Perform the following steps to add the IP addresses of the network services perimeter ISA firewall’s default Internal Network to the definition of the front-end ISA firewall’s default Internal Network:

[LIST=1][*]In the ISA firewall console, expand the server name and then expand the [B]Configuration[/B] node. Click on the [B]Networks[/B] node.[*]On the [B]Networks [/B]node, click the [B]Networks[/B] tab in the details pane, then double click the [B]Internal[/B] Network.[*]In the [B]Internal Properties[/B] dialog box, click the [B]Addresses[/B] tab.[*]On the [B]Addresses[/B] tab, click the [B]Add[/B] button.[*]In the [B]IP Address Range Properties[/B] dialog box, enter the [B]Starting address[/B] and the [B]Ending address[/B] in the text boxes. In this example we’ll enter [B]10.0.0.0[/B] and [B]10.0.0.255[/B], respectively. Click [B]OK[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0041130424651356.jpg[/IMG]
[B]Figure 1[/B][/INDENT]
[LIST=1][*]Click [B]OK[/B] in the [B]Internal Properties[/B] dialog box[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0061130424651356.jpg[/IMG]
[B]Figure 2[/B][/INDENT]IP addressing information for hosts on the Corpnet is determined by your requirements. The most secure configuration is to not provide users with a default gateway address that provides a route to the Internet. This forces all users to use the Firewall client and Web proxy configuration, which can be used to enforce strong user/group-based access controls, as well as block applications installed on users’ computers from accessing the Internet. This also prevents users from using non-Winsock or Web proxy compliant applications, such as ICMP utilities like PING and TRACERT.
Administrative users and servers can be configured with gateway addresses that route to the Internet. Administrators require the use of ICMP based utilities, and servers do not have logged on users, so both admins and servers require the facilities provided by the SecureNAT client configuration.
[B]Create a Routing Table Entry on the Edge ISA Firewall[/B]

A routing table entry must be configured on the edge ISA firewall so that it knows the path to take to reach the network services segment. The ISA firewall should always be configured with routing table entries for all network IDs that can’t be reached using the default gateway. In practice, this usually means that, except for Internet addresses, there should be a routing table entry on the ISA firewall for all network IDs on your corporate network.
Note that if your ISA firewall is configured with a default gateway pointing to a LAN router, and all network IDs are reachable from that router, then there’s no reason to enter all network IDs in the ISA firewall’s routing table, since the LAN router is doing the router duties.
At the edge ISA firewall, open a command prompt and enter the following:
[INDENT] route add –p 10.0.0.0 MASK 255.255.255.0 10.0.1.2[/INDENT]Where [B]10.0.0.0[/B] is the network ID for the network services segment behind the network service perimeter ISA firewall, [B]255.255.255.0[/B] is the subnet mask for that network ID, and [B]10.0.1.2[/B] is the IP address on the external interface of the back-end ISA firewall.
The figure below shows an example of configuring the routing table entry.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0081130424651372.jpg[/IMG]
[B]Figure 3[/B][/INDENT][B]Join the Edge ISA Firewall to the Domain[/B]

The edge ISA firewall should be a member of the domain so that you can fully leverage both the Firewall and Web proxy client configuration. While you can use RADIUS authentication for Web proxy clients, there are significant limitations to RADIUS authentication in both the logging and management realms. For this reason, I recommend that you avoid RADIUS authentication if at all possible. In addition, you must make the edge ISA firewall a domain member if you want to fully leverage the enhanced security and flexibility provided by the Firewall client.
The edge ISA firewall will be able to use the intradomain communications Access Rule created on the network services perimeter ISA firewall to access the domain controller. The edge ISA firewall is configured to use the DNS server on the network services segment and the DNS server on the network services segment is configured to support name resolution within the network and also for Internet host names.
[B]Create Access Rules on the Edge ISA Firewall Controlling Outbound Access from Corpnet Hosts and Hosts on the Network Services Segment[/B]

Firewall policy on the edge ISA firewall will be highly customized based on your own network’s security requirements. You will need to decide together with your network security team who should have access to what sites and Web site at what times of day. Firewall policy is definitely something where one size does not fit all.
In the example provided by our sample network configuration, all hosts on the Corpnet ISA firewall Network are configured as Firewall and Web proxy clients and are [I]not[/I] configured as SecureNAT clients. The only exception is for administrator workstations, since network administrators will need access to non-Winsock protocols and utilities, such as PING and TRACERT.
We will create the following Access Rules:

[LIST][*]An Access Rule allowing the DC on the network services segment access to DNS outbound[*]An Access Rule allowing all authenticated users outbound access to all protocols. Note that in a production environment, you would create more granular access controls and create ISA firewall Groups that allow users to access only the content they require to get their jobs done[*]An Access Rule allowing the servers on the network services segment access to the Windows reporting and Microsoft Update sites. We need this rule because the servers on the network services segment do not have logged on users, so we will not be able to leverage the Firewall client to force authentication from server connections.[/LIST]
Table 1 shows the salient characteristics of these Access Rules.
[INDENT] [B]Table 1: Access Rules on the edge ISA Firewall[/B]

[B]Order[/B]
[B]Name[/B]
[B]Action[/B]
[B]Protocols[/B]
[B]From/Listener[/B]
[B]To[/B]
[B]Condition[/B]
1
MU and Error Reporting – Servers
Allow
HTTP
HTTPS
Network Service Segment
Microsoft Error Reporting Sites
System Policy Allowed Sites
All Users
2
Outbound DNS for DNS Server
Allow
DNS
DNS Server*
External
All Users
3
All Open – Authenticated
Allow
All Outbound Traffic
Internal
External
All Authenticated Users
[I]* Note discussion below on the From configuration for this Access Rule [/I][/INDENT][B]Create the Outbound DNS for DNS Server Access Rule [/B]
Perform the following steps to create the Access Rule allowing the domain controller on the network services segment outbound access to the DNS protocol:

[LIST=1][*]On the edge ISA firewall, open the ISA firewall console and click the [B]Firewall Policy[/B] node.[*]On the [B]Firewall Policy[/B] node, click the [B]Tasks[/B] tab on the Task Pane and click [B]Create New Access Rule [/B][*]On the [B]Welcome to the New Access Rule Wizard[/B] page, enter a name for the rule in the [B]Access Rule name[/B] text box. In this example we’ll name the rule [B]Outbound DNS for DNS Server[/B] and click [B]Next[/B].[*]Select the [B]Allow[/B] option on the [B]Rule Action[/B] page. Click [B]Next[/B].[*]On the [B]Protocols[/B] page, select the [B]Selected protocols[/B] option from the [B]This[/B][B] rule applies to[/B] list and click [B]Add[/B].[*]In the [B]Add Protocols[/B] dialog box, click the [B]Common Protocols[/B] folder and double click on the [B]DNS[/B] entry. Click [B]Close[/B].[*]Click [B]Next[/B] on the [B]Protocols[/B] page.[*]On the [B]Access Rule Sources[/B] page, click the [B]Add[/B] button.[*]In the [B]Add Network Entities[/B] dialog box, click the [B]New[/B] menu and click [B]Computer[/B].[*]In the [B]New Computer Rule Element[/B] dialog box, enter a name for the computer in the [B]Name[/B] text box. In this example we’ll name the computer [B]DNS Server[/B]. Enter the IP address of the external interface of the network services segment perimeter ISA firewall. Note that we use the IP address of the external interface of the perimeter ISA firewall because there is a NAT relationship between the perimeter ISA firewall’s default Internal Network and its default External Network. Since the DNS queries the DNS server makes are to Internet-based DNS server, the connection will be NATed. When the connection is NATed, the source IP address of the outbound connection is the primary IP address on the external interface of the perimeter ISA firewall. In this example, the IP address is [B]10.0.1.2[/B], so we’ll enter that address. Enter an optional description if you like. Click [B]OK[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0101130425589685.jpg[/IMG]
[B]Figure 4[/B][/INDENT]
[LIST=1][*]In the [B]Add Network Entities[/B] dialog box, click the [B]Computers[/B] folder and double click the [B]DNS Server[/B] entry. Click [B]Close[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0121130425589685.jpg[/IMG]
[B]Figure 5[/B]
[/INDENT]
[LIST=1][*] Click [B]Next[/B] on the [B]Access Rule Sources[/B] page.[*] Click [B]Add[/B] on the [B]Access Rule Destinations[/B] page.[*] In the [B]Add Network Entities[/B] dialog box, click the [B]Networks[/B] folder and then double click [B]External[/B]. Click [B]Close[/B].[*] Click [B]Next[/B] on the [B]Access Rule Destinations[/B] page.[*] Click [B]Next[/B] on the [B]User Sets[/B] page.[*] Click [B]Finish[/B] on the [B]Completing the New Access Rule Wizard[/B] page.[/LIST]
[CENTER][/CENTER]
[CENTER][B][URL="http://www.amazon.com/exec/obidos/ASIN/1931836191/ref%3Dnosim/searchbyisbn/wwwshindernet-20/103-2457787-0455800"]
[/URL][/B][/CENTER]
[B]Create the All Open Rule for Authenticated Users[/B]
Perform the following steps to create the outbound Access Rule allowing all authenticated users outbound access to all protocols and sites:

[LIST=1][*]On the edge ISA firewall, open the ISA firewall console and click the [B]Firewall Policy[/B] node.[*]On the [B]Firewall Policy[/B] node, click the [B]Tasks[/B] tab on the Task Pane and click [B]Create New Access Rule [/B][*]On the [B]Welcome to the New Access Rule Wizard[/B] page, enter a name for the rule in the [B]Access Rule name[/B] text box. In this example we’ll name the rule [B]All[/B][B] Open -- Authenticated[/B] and click [B]Next[/B].[*]Select the [B]Allow[/B] option on the [B]Rule Action[/B] page. Click [B]Next[/B].[*]On the [B]Protocols[/B] page, select the [B]All outbound traffic [/B]option from the [B]This[/B][B] rule applies to[/B] list and click [B]Next[/B].[*]Click [B]Next[/B] on the [B]Protocols[/B] page.[*]On the [B]Access Rule Sources[/B] page, click the [B]Add[/B] button.[*]In the [B]Add Network Entities[/B] dialog box, click the [B]Networks[/B] folder and then double click [B]Internal[/B]. Click [B]Close[/B].[*]Click [B]Next[/B] on the [B]Access Rule Sources[/B] page.[*]Click [B]Add[/B] on the [B]Access Rule Destinations[/B] page.[*]In the [B]Add Network Entities[/B] dialog box, click the [B]Networks[/B] folder and then double click [B]External[/B]. Click [B]Close[/B].[*]Click [B]Next[/B] on the [B]Access Rule Destinations[/B] page.[*]On the [B]User Sets[/B] page, click the [B]All Users[/B] entry and click [B]Remove[/B]. Click [B]Add[/B].[*]In the [B]Add Users[/B] dialog box, double click on the [B]All Authenticated Users[/B] entry and click [B]Close[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0141130425609341.jpg[/IMG]
[B]Figure 6[/B][/INDENT]
[LIST=1][*]Click [B]Next[/B] on the [B]User Sets[/B] page.[*]Click [B]Finish[/B] on the [B]Completing the New Access Rule Wizard[/B] page.[/LIST]
[B]Create the Microsoft Update and Error Reporting Sites Access Rule [/B]
Perform the following steps to create the Access Rule allowing servers on the network services segment access to the Windows Update sites and the Microsoft Error Reporting sites:

[LIST=1][*]On the edge ISA firewall, open the ISA firewall console and click the [B]Firewall Policy[/B] node.[*]On the [B]Firewall Policy[/B] node, click the [B]Tasks[/B] tab on the Task Pane and click [B]Create New Access Rule [/B][*]On the [B]Welcome to the New Access Rule Wizard[/B] page, enter a name for the rule in the [B]Access Rule name[/B] text box. In this example we’ll name the rule [B]MU and Error Reporting -- Servers[/B] and click [B]Next[/B].[*]Select the [B]Allow[/B] option on the [B]Rule Action[/B] page. Click [B]Next[/B].[*]On the [B]Protocols[/B] page, select the [B]Selected protocols[/B] option from the [B]This[/B][B] rule applies to[/B] list and click [B]Add[/B].[*]In the [B]Add Protocols[/B] dialog box, click the [B]Common Protocols[/B] folder and double click on the [B]HTTP [/B]and [B]HTTPS[/B] entries. Click [B]Close[/B].[*]Click [B]Next[/B] on the [B]Protocols[/B] page.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0161130425609341.jpg[/IMG]
[B]Figure 7[/B][/INDENT]
[LIST=1][*]On the [B]Access Rule Sources[/B] page, click the [B]Add[/B] button.[*]In the [B]Add Network Entities[/B] dialog box, click the [B]New[/B] menu and click [B]Address[/B][B] Range[/B].[*]In the [B]New Address Range Rule Element[/B] dialog box, enter a name for the address range in the [B]Name[/B] text box. In this example we’ll name it [B]Network Services Segment[/B]. Enter the start and end addresses in the [B]Start Address[/B] and [B]End Address[/B] text boxes. Enter an optional description and then click [B]OK[/B][/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0181130425636528.jpg[/IMG]
[B]Figure 8[/B][/INDENT]
[LIST=1][*]In the [B]Add Network Entities[/B] dialog box, click the [B]Address[/B][B] Ranges[/B] folder and double click the [B]Network Services Segment [/B]entry. Click [B]Close[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0201130425636528.jpg[/IMG]
[B]Figure 9[/B][/INDENT]
[LIST=1][*]Click [B]Next[/B] on the [B]Access Rule Sources[/B] page.[*]Click [B]Add[/B] on the [B]Access Rule Destinations[/B] page.[*]In the [B]Add Network Entities[/B] dialog box, click the [B]Domain Name Sets[/B] folder and double click [B]Microsoft Error Reporting sites [/B]and [B]System Policy Allowed Sites[/B]. Click [B]Close[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0221130425636560.jpg[/IMG]
[B]Figure 10[/B][/INDENT]
[LIST=1][*]Click [B]Next[/B] on the [B]Access Rule Destinations[/B] page.[*]Click [B]Next[/B] on the [B]User Sets[/B] page.[*]Click [B]Finish[/B] on the [B]Completing the New Access Rule Wizard[/B] page.[/LIST]
Before applying the configuration to the ISA firewall’s firewall policy, make sure that you put the unauthenticated Access Rules before the authenticated rules. This is a good general approach to ordering firewall rules on your ISA firewall.
Click [B]Apply [/B]to save the changes and update the firewall policy. Click [B]OK[/B] in the [B]Apply New Configuration[/B] dialog box. Your firewall policy should look like that in the figure below.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0241130425636575.jpg[/IMG]
[B]Figure 11[/B][/INDENT][B]Create Publishing Rules on the Edge ISA Firewall to Allow Inbound Connections to the Exchange Server Mail Services[/B]

Now we’re ready to create publishing rules allowing access to Exchange Server services for users on the Internet. We’ll create Server Publishing Rules that allow access to the OWA, Secure Exchange RPC, SMTP, POP3 and IMAP4 services.
[B]Create an SSL Server Publishing Rule on the Network Services Perimeter ISA Firewall[/B]
We begin by creating an SSL Server Publishing Rule on the front end ISA firewall. We must create a Server Publishing Rule instead of a Web Publishing Rule because the OWA form generated by the network services perimeter ISA firewall cannot deliver the log on form through a Web proxy connection on the edge ISA firewall. The SSL Server Publishing Rule will enable a secure end to end connection but will not allow the edge ISA firewall to perform stateful application layer inspection on the SSL connection moving through the edge ISA firewall.
This is a limitation of our sample network design and should not be construed to imply that you can never use OWA FBA in a back to back ISA firewall configuration. For example, suppose you have a back to back ISA firewall configuration with a DMZ between the front-end and back-end ISA firewalls. You can use FBA on the front-end ISA firewall and configure the front-end ISA firewall’s OWA Web Publishing Rule to forward basic credentials to the back-end ISA firewall’s Web Publishing Rule. The back-end ISA firewall is configured to use basic authentication. In this case, we have single sign-on with FBA.
[B]Create the Network Services Perimeter Network OWA Web Publishing Rule [/B]
Perform the following steps on the edge ISA firewall to enable inbound access to the network services perimeter ISA firewall’s OWA Web Publishing Rule:

[LIST=1][*]In the ISA firewall console, expand the server name and click the [B]Firewall Policy[/B] node.[*]On the [B]Firewall Policy[/B] node, click the [B]Tasks[/B] tab on the Task Pane and then click the [B]Publish a Secure Web Server[/B] link.[*]On the [B]Welcome to the SSL Web Publishing Rule Wizard[/B] page, enter a name for the rule in the [B]SSL Web Publishing Rule name[/B] text box. In this example we’ll name the rule [B]SSL tunnel to OWA[/B] and click [B]Next[/B].[*]On the [B]Publishing Mode[/B] page, select the [B]SSL Tunneling[/B] option and click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0261130426009419.jpg[/IMG]
[B]Figure 12[/B][/INDENT]
[LIST=1][*]On the [B]Select Server[/B] page, enter the IP address of the external interface of the network services perimeter ISA firewall. This is the address used by the listener on the OWA Web Publishing Rule on the network services perimeter ISA firewall. In this example the IP address is [B]10.0.1.2[/B], so we’ll enter that address and click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0281130426009419.jpg[/IMG]
[B]Figure 13[/B][/INDENT]
[LIST=1][*] On the [B]IP Addresses[/B] page, put a checkmark in the [B]External[/B] checkbox and click [B]Next[/B].[*] Click [B]Finish[/B] on the [B]Completing the New SSL Web Publishing Rule Wizard[/B] page.[/LIST]
At this point, your firewall policy should look like that in the figure below.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0301130426009419.jpg[/IMG]
[B]Figure 14[/B][/INDENT][B]Create Secure Exchange RPC, SMTP, POP3 and IMAP4 Server Publishing Rules [/B]

The next step is to create the Server Publishing Rules on the edge ISA firewall that provide access to the Server Publishing Rules configured on the network services perimeter ISA firewall. These Server Publishing Rules enable Internet based hosts access to the Exchange Server services on the network services segment.
[B]Create the Mail Server Publishing Rules[/B]
Perform the following steps to create the Server Publishing Rules on the edge ISA firewall:

[LIST=1][*]In the ISA firewall console, expand the server name and then click the [B]Firewall Policy[/B] node.[*]On the [B]Firewall Policy[/B] node, click the [B]Tasks[/B] tab on the Task Pane and click the [B]Publish a Mail Server [/B]link.[*]On the [B]Welcome to the New Mail Server Publishing Rule Wizard[/B] page, enter a name for the rule in the [B]Mail Server Publishing Rule name[/B] text box. In this example, we’ll name the rule [B]Exchange Server[/B] and click [B]Next[/B].[*]On the [B]Select Access Type[/B] page, select the [B]Client access: RPC, IMAP, POP3, SMTP[/B] option and click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0321130426009419.jpg[/IMG]
[B]Figure 15[/B][/INDENT]
[LIST=1][*]On the [B]Select Services[/B] page, put a checkmark in each of the checkboxes. This will allow us to connect to the Exchange Server on the network services segment through the network services perimeter ISA firewall for all the services listed on this page. Note the comment on the page regarding the SMTP Message Screener. We will not deploy the message screener in this example, but you might want to consider it in your own deployment. You can install the SMTP Message Screener on the ISA firewall to filter both inbound and outbound mail. Even though the SMTP Message Screener won’t be enabled, the SMTP filter is enabled and will protect SMTP communications. Click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0341130426496216.jpg[/IMG]
[B]Figure 16[/B][/INDENT]
[LIST=1][*]On the [B]Select Server[/B] page, enter the IP address of the Exchange Server on the network services segment in the [B]Server IP address[/B] text box. In this example, the IP address is [B]10.0.0.2[/B], so we enter that value. Click [B]Next[/B].[*]On the [B]IP Addresses[/B] page, put a checkmark in the [B]External[/B] checkbox. Click [B]Next[/B].[*]Click [B]Finish[/B] on the [B]Completing the New Mail Server Publishing Rule Wizard[/B] page.[/LIST]
Your Firewall Policy should appear similar to that in the figure below. Note that the Mail Server Publishing Rule Wizard added seven new Server Publishing Rules. Click [B]Apply [/B]to save the changes and update the firewall policy. Click [B]OK[/B] in the [B]Apply New Configuration[/B] dialog box.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0361130426496294.jpg[/IMG]
[B]Figure 17[/B][/INDENT]There is one more thing we need to do on the edge ISA firewall to make the Server Publishing Rules work correctly. Because there is a Route relationship between the Corpnet ISA firewall Network and the network services segment, we will need to change the Server Publishing Rules on the edge ISA firewall so that the client requests appear to come from the edge ISA firewall. This allows us to use the Server Publishing Rules we created on the network services perimeter ISA firewall where the listener is listening on the Corpnet ISA firewall Network.
[B]Configure the Server Publishing Rules to Use the ISA Firewall’s Address as the Source IP Address[/B]
For each of the Server Publishing Rules created by Mail Server Publishing Wizard, perform the following steps:

[LIST=1][*]Double click on one of the Server Publishing Rules created by the Server Publishing Rule Wizard.[*]In the [B]Properties[/B] dialog box for that rule, click the [B]To[/B] tab.[*]On the [B]To[/B] tab, select the [B]Request appear to come from the ISA Server computer[/B] option. Click [B]OK[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0381130426496294.jpg[/IMG]
[B]Figure 18[/B][/INDENT]
[LIST=1][*]Repeat the procedure for all the Server Publishing Rules created by the Mail Server Publishing Rule Wizard.[*]Click [B]Apply [/B]to save the changes and update the firewall policy.[*]Click [B]OK[/B] in the [B]Apply New Configuration[/B] dialog box.[/LIST]
[CENTER]

[URL="http://www.amazon.com/exec/obidos/ASIN/1931836191/ref%3Dnosim/searchbyisbn/wwwshindernet-20/103-2457787-0455800"]
[/URL][/CENTER]
[B]Summary[/B]

In this, part 4 of our series on creating a network service segment using an internal ISA firewall, we moved our attention to the edge ISA firewall. We created Server Publishing Rule publishing rules that allowed inbound access to Exchange Server services through the edge ISA firewall so that users located on the Internet are able to reach Exchange services from any location in the world. In the next article in this series, we’ll configure hosts on the Corpnet ISA firewall Network, configure the internal DNS and configure the settings used by Firewall and Web proxy clients.
[/LEFT]

[LEFT][CODE]http://www.isaserver.org/tutorials/Configure-ISA-2004-Network-Services-Segment-Perimeter-Firewall-Part5.html[/CODE]
[B][SIZE=3]
[/SIZE][/B][B][B][SIZE=3]Part 5: Configuring the Clients and DNS Infrastructure[/SIZE][/B][/B]


In the first four parts of this series on creating a network services segment using ISA firewalls, we discussed general DMZ and perimeter segment networking principles and design concepts, configuration of the network services segment ISA firewall, and routing principles and procedures required to make our solution work. We also configured the edge ISA firewall so that users on the Corpnet ISA firewall Network could gain access to Internet resources and external users could access Exchange Server resources located on the network services segment.
In this, part 5 of the article series, we’ll focus on the network client systems. We perform the following procedures in this article:

[LIST][*]Create a Routing table Entry on the Network Clients (only required if there are no LAN routers installed)[*]Join the Network Clients to the Domain[*]Create Configure DNS Entries in the Domain DNS, Including WPAD Entries[*]Configure the Firewall Client Settings on the Edge ISA Firewall (including Web Proxy Client Configuration)[*]Install the Firewall Client Share on the Network Services Segment File Server[*]Install the Firewall Client on the Network Clients[*]Connect the Corporate Network Clients to Resources on the Network Services Segment and the Internet[/LIST]

[B]Create a Routing table Entry on the Network Clients (only required if there are no LAN routers installed)[/B]

Clients on the Corpnet ISA firewall Network need to know the route to the network services segment. As discussed in part 1 of this article series, you have two options: use LAN routers that contain the appropriate routing table entries to reach the network services segment or configure the clients with a routing table entry.
In the example used in this article, we’ll create routing table entries on the clients. You can automate this process by using a log on script that contains the [B]Route add[/B] command used to add the routing table entry. The command required is:
[INDENT] [B]Route add –p 10.0.0.0 MASK 255.255.255.0 10.0.1.2[/B][/INDENT]Where [B]–p[/B] makes the routing table entry permanent, [B]10.0.0.0[/B] is the network ID of the network services segment, [B]255.255.255.0[/B] is the subnet mask for the network services segment, and [B]10.0.1.2[/B] is the gateway address used to reach that network.
[B]Join the Network Clients to the Domain[/B]

All the pieces are now in place to add the network clients to the domain. The network services perimeter ISA firewall has the appropriate Access Rules in place to join hosts on the Corpnet ISA firewall Network to the domain. The procedure varies with the operating system you’re joining to the domain. In the example used in this article series, we’re joining a Windows XP client to the domain.
[B]Create Configure DNS Entries in the Domain DNS, Including WPAD Entries[/B]

DNS infrastructure design is critical for all Windows environments. One of the most common reasons for connectivity and performance issues is a poorly designed DNS infrastructure. Proper DNS infrastructure is critically important in ISA firewall networking because the ISA firewall uses DNS name resolution for access control and security monitoring.
Clients on the Corpnet ISA firewall Network will be configured as both Web proxy and Firewall clients. Web proxy and Firewall clients need to be able to locate the edge ISA firewall to access the Internet. While you can manually configure each host with the proper information, it’s much easier to automate the process using WPAD entries in DNS and/or DHCP.
Web proxy and Firewall clients use WPAD entries in DNS and/or DHCP to find the address of the ISA firewall. After the clients find the address of the ISA firewall, the clients obtain configuration information from the ISA firewall. By default the ISA firewall advertises configuration information on TCP port 80, which can be changed if required. However, if you use DNS-based WPAD entries, you [I]must[/I] use TCP port 80. If you use DHCP for WPAD information, you can use any port you like to advertise autodiscovery information.
In the example used in this series, we will use DNS WPAD publishing. We will create a WPAD CNAME record based on the Host (A) record for the edge ISA firewall. The Host (A) record for the edge ISA firewall maps the name of the edge ISA firewall to the IP address on the internal interface of the edge ISA firewall.
Perform the following steps to create the WPAD entry on the domain DNS server on the network services segment:

[LIST=1][*]At the DNS server, click [B]Start[/B], point to [B]Administrative Tools[/B] and click [B]DNS[/B].[*]In the [B]DNS [/B]console, expand the server name and then expand the [B]Forward Lookup Zones[/B] node. Click on the domain, which in this case is [B]msfirewall.org[/B].[*]Right click the domain name and click [B]New Alias (CNAME)[/B].[*]In the [B]New Resource Record[/B] dialog box, enter [B]wpad[/B] in the [B]Alias name (uses parent domain if left blank)[/B] text box. Click the [B]Browse[/B] button.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0021131364928942.jpg[/IMG]
[B]Figure 1[/B][/INDENT]
[LIST=1][*]Double click the server name in the [B]Records[/B] section, then double click the [B]Forward Lookup Zone[/B] entry. Double click the domain name and then double click the entry for the edge ISA firewall. In this example the name of the edge ISA firewall is [B]remoteisa[/B], so I’ll double click that one.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0041131364928942.jpg[/IMG]
[B]Figure 2[/B][/INDENT]
[LIST=1][*]Click [B]OK[/B] in the [B]New Resource Record[/B] dialog box.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0061131367322504.jpg[/IMG]
[B]Figure 3[/B][/INDENT]
[LIST=1][*] The new CNAME record appears in the right pane of the console.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0081131367322504.jpg[/IMG]
[B]Figure 4[/B][/INDENT]Note that the edge ISA firewall’s IP address is included in the domain DNS because it was automatically added when the firewall joined the domain. If your domain DNS is not configured to enable automatic registration of DNS records, then you’ll need to create the Host (A) record yourself before you can create the CNAME record.
[CENTER]

[URL="http://www.amazon.com/exec/obidos/ASIN/1931836191/ref%3Dnosim/searchbyisbn/wwwshindernet-20/103-5455432-1772662"]
[/URL][/CENTER]
[B]Configure the Firewall and Web Proxy Client Settings on the Edge ISA Firewall and Enable Autodiscovery[/B]

In my experience, who of the least understood issues with ISA firewall configuration relates to the settings in the Firewall client configuration on the ISA firewall. For each ISA firewall Network, you can configure Firewall client settings that are used by Firewall client systems located on that ISA firewall Network. These settings allow you to set how the Firewall client software finds the ISA firewall and what destination addresses should be remoted to the ISA firewall and which ones should not be serviced by the Firewall client software.
The best way to learn how these settings work is to get into the configuration interface. Perform the following steps on the edge ISA firewall to configure the Firewall client settings:

[LIST=1][*]In the ISA firewall console, expand the server name and then expand the [B]Configuration[/B] node. Click the [B]Networks[/B] node.[*]On the [B]Networks[/B] node, double click the default [B]Internal[/B] Network entry.[*]In the [B]Internal Properties[/B] dialog box, click the [B]Firewall Client[/B] tab. On the [B]Firewall Client[/B] tab, confirm that there is a checkmark in the [B]Enable Firewall client support for this network[/B] checkbox. When this option is enabled, the Firewall client listener port, TCP 1745, is enabled and listens for connections from the Firewall clients on that ISA firewall Network. In the [B]ISA Server name or IP address[/B] text box, enter the fully qualified domain name of the ISA firewall. This is a critical setting. The default entry in this text box is the NetBIOS name of the ISA firewall, which can create problems with name resolution. The name you enter into this text box is the name Firewall clients on the network will use to access the ISA firewall. If you leave just the NetBIOS name in this text box, there could be problems with name resolution related to fully qualifying the unqualified name. While I am not saying that it won’t work to leave just the NetBIOS name in this text box, I am saying that you will avoid difficult to troubleshoot issues with Firewall clients if you use a FQDN in this text box. Put a checkmark in the [B]Automatically detect settings[/B] checkbox and do [I]not[/I] enable the [B]Use automatic configuration script[/B] and [B]Use a Web proxy server[/B] checkboxes. You will get autoconfiguration information by using autodiscovery, and you don’t need the [B]Use a Web proxy server[/B] setting because the client will find the Web proxy filter component of the ISA firewall using the wpad settings.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0101131367322504.jpg[/IMG]
[B]Figure 5[/B][/INDENT]
[LIST=1][*]Click the [B]Domains[/B] tab. On this tab you enter your internal domain names so that the Firewall clients do not use the Firewall client software to handle connections to hosts on the Internal domains. This is a tricky setting on multihomed ISA firewalls with multiple internal ISA firewall Networks, but in this example, the edge ISA firewall has only a single internal Network, so we won’t run into those issues. I will discuss in deep detail the configuration issues with the [B]Domains[/B] tab on multihomed ISA firewalls with multiple internal ISA firewall Networks is another series on creating network services segments using multihomed ISA firewalls. In this example, we have a single internal domain, which is [B]msfirewall.org[/B]. Click [B]Add[/B] to enter the internal network domain.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0121131368593707.jpg[/IMG]
[B]Figure 6[/B][/INDENT]
[LIST=1][*]In the [B]Domain Properties[/B] dialog box, enter the name of the internal domain in the [B]Enter a domain name to include[/B] text box. Click [B]OK[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0141131368593754.jpg[/IMG]
[B]Figure 7[/B][/INDENT]We can also configure the Web proxy client settings in the [B]Properties[/B] dialog box of the ISA firewall Network. Continue with the following steps to configure the Web proxy client configuration:
In the [B]Internal Properties[/B] dialog box, click the [B]Web Browser[/B] tab. On the [B]Web Browser[/B] tab, confirm that there are checkmarks in the [B]Bypass proxy for Web server in this network[/B] and [B]Direct access computers specified in the Domains tab[/B]. The [B]Bypass proxy for Web servers in this network [/B]setting allows the Web proxy client machines to bypass their Web proxy configuration when connecting to servers using a [I]single label name[/I]. For example, [url]http://server1[/url] is a single label name. When the single label name is used, the Web browser ignores the Web proxy settings and connects directly to the Web server. This is known as [I]Direct Access[/I]. When Direct Access is used, the client system must be able to resolve the name itself, as the ISA firewall does not handle the connection and therefore does not perform name resolution on behalf of the client.

The [B]Directly access computers specified in the Domains tab[/B] option enables the Web proxy client system to bypass the Web proxy configuration when connecting to hosts that belong to a domain included in the [B]Domains[/B] tab. This is a useful option because the Web proxy client bypasses its Web proxy configuration and the ISA firewall when connecting to internal, trusted servers on the corporate network.

You can also add servers, domains and addresses for Direct Access by clicking the [B]Add[/B] button next to the [B]Directly access these servers or domains[/B] list. You might want to put all the addresses in the ISA firewall Network in the Direct Access list. For example, since we’re in the [B]Internal Properties[/B] dialog box, we could include all the addresses in the default [B]Internal[/B] network. In a multihomed, multiple internal Network design, this can be used for authenticated access control, but we’ll talk about these issues in the series on creating network services segments using a multihomed ISA firewall.

Confirm that there is a checkmark in the [B]If ISA Server is unavailable, use this backup route to connect to the Internet[/B] checkbox and that the [B]Direct Access[/B] option is selected.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0161131368593926.jpg[/IMG]
[B]Figure 8[/B][/INDENT]The last thing we need to do in the [B]Internal Properties[/B] dialog box is enable [B]Autodiscovery[/B] publishing. Perform the following steps to enable the ISA firewall to publish autodiscovery information:

[LIST=1][*]Click [B]Auto Discovery[/B] tab in the [B]Internal Properties[/B] dialog box.[*]On the [B]Auto Discovery[/B] tab, put a checkmark in the [B]Publish automatic discovery information [/B]checkbox. Leave the default port listed in the [B]Use this port for automatic discovery request[/B] text box as [B]80[/B]. We must use TCP port 80 since we are using DNS for out WPAD entry.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0181131368593973.jpg[/IMG]
[B]Figure 9[/B][/INDENT]
[LIST=1][*] Click [B]OK[/B] in the [B]Internal Properties[/B] dialog box.[*] Click [B]Apply [/B]to save the changes and update the firewall policy.[*] Click [B]OK[/B] in the [B]Apply New Configuration[/B] dialog box.[/LIST]
[B]Install the Firewall Client Share on the Network Services Segment File Server[/B]

The Firewall client software will be installed on all the client systems on the Corpnet ISA firewall Network. Note that you should only install the Firewall client software on network client systems, and avoid installing it on servers. While it is possible to install the Firewall client software on servers, there is little reason to do so, since servers typically do not have logged on users (interactive log ons, that is). You will avoid difficult to diagnose connectivity issues if you do not install the Firewall client software on network servers.
While some ISA firewall administrators choose to install the Firewall client share on the ISA firewall itself, I highly recommend against this practice, as it requires Windows file sharing protocol connections to be made to the ISA firewall device itself. This opens a potential security hole that does not need to be opened. Instead, install the Firewall client share on a file server on the network services segment. Remember, the ISA firewall is a network level security device and connections to and from the ISA firewall device should be severely limited.
Perform the following steps on the file server computer on the network services segment:

[LIST=1][*]At the file server on the network services segment, place the ISA Server 2004 CD into the CD-ROM drive. The autorun menu will appear. If the autorun menu does not appear, double click the [B]isaautorun.exe[/B] file on the CD.[*]In the [B]ISA Server 2004 Setup[/B] autorun menu, click the [B]Install ISA Server 2004 [/B]link.[*]Click [B]Next[/B] on the [B]Welcome to the Installation Wizard for Microsoft ISA Server 2004 [/B]page.[*]Select the [B]I accept the terms in the license agreement[/B] option on the [B]License Agreement[/B] page and click [B]Next[/B].[*]Enter your user information and product serial number on the [B]Customer Information[/B] page and click [B]Next[/B].[*]Select the [B]Custom [/B]option on the [B]Setup Type[/B] page.[*]On the [B]Custom Setup[/B] page, click the [B]ISA Server Management[/B] icon and click the [B]This feature will not be available[/B] option. Click the [B]Firewall Client Installation Share[/B] icon and click the [B]This feature, and all subfeatures, will be installed on local hard drive[/B] option. Click [B]Next[/B]. [IMG]http://www.isaserver.org/img/upl/image0201131368620567.jpg[/IMG]
[B]Figure 10[/B][*]Click [B]Install[/B] on the [B]Ready to Install the Program[/B] page.[*]Click [B]Finish[/B] on the [B]Installation Wizard Completed[/B] page.[*]Close the Internet Explorer window that presents a page on how to [B]Protect the ISA Server Computer[/B].[*]Click the [B]Exit[/B] link on the ISA autorun menu.[/LIST]
[B]Install the Firewall Client on the Network Clients[/B]

The Firewall client share is now installed on the file server and can be accessed using the \\server_name\mspclnt\setup.exe UNC path. Any user logged on as a local administrator can install the Firewall client software. However, if not all your users run as local administrators, you’ll need to find another way to install the Firewall client software.
Fortunately, the ideal solution to this problem is Active Directory Group Policy based software installation. Since the client machines must be domain members to fully utilize the flexibility and increased security provided by the Firewall client, those domain members can have their Firewall client software installed automatically via Group Policy.
In the following procedure we will create an OU for machines that should have the Firewall client software automatically installed. We do this to prevent the Firewall client software from being installed on servers. There may be more elegant ways to approach this, such as using Group Policy filtering, but I’ll leave that up to the Active Directory guys to figure out the most efficient way to assigning the Firewall client software only to client systems and not servers.
Note that in the following example we’ll create an OU that provides a GPO linked to the OU that installs the Firewall client software. In a production environment, you will want to link other GPOs to the OU and order the GPO links appropriately.
Perform the following steps to create the OU, place a client system in the OU, and then use Software Installation to assign the Firewall client software to members of the OU:

[LIST=1][*]On the domain controller on the network services segment, open the [B]Active Directory Users and Computers[/B] console from the [B]Administrative Tools[/B] menu.[*]Right click on the domain name, point to [B]New[/B] and click [B]Organizational Unit[/B].[*]In the [B]New Object – Organizational Unit[/B] page, enter [B]Firewall Client Systems[/B] in the [B]Name[/B] text box. Click [B]OK[/B].[*]Click the [B]Computers[/B] node and right click the client system name in the right pane of the console. Click [B]Move[/B].[*]In the [B]Move[/B] dialog box, click the [B]Firewall Client Systems[/B] node and click [B]OK[/B].[*]Right click the [B]Firewall Client Systems[/B] OU and click [B]Properties[/B].[*]In the [B]Firewall Client Systems[/B] [B]Properties[/B] dialog box, click the [B]Group Policy [/B]tab.[*]On the [B]Group Policy[/B] tab, click the [B]New[/B] button. Name the new GPO [B]Firewall Client Installation[/B] and click [B]Edit[/B].[*]In the [B]Group Policy Object Editor[/B] console, expand the [B]Computer Configuration [/B]node and then expand the [B]Software Settings[/B] node. Right click [B]Software installation[/B], point to [B]New[/B] and click [B]Package[/B].[*]In the [B]Open[/B] dialog box, enter the UNC path to the Firewall client installation package file. In this example, the path is [B]\\Win2k\mspclnt\MS_FWC.msi[/B]. Click [B]Open[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0221131368620582.jpg[/IMG]
[B]Figure 11[/B][/INDENT]11. In the [B]Deploy Software[/B] dialog box, select the [B]Assigned[/B] option and click [B]OK[/B].
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0241131368620598.jpg[/IMG]
[B]Figure 12[/B][/INDENT]
[LIST=1][*] Close the [B]Group Policy Object Editor[/B].[*] Close the [B]Firewall Client Systems Properties[/B] dialog box.[*] Close [B]Active Directory Users and Computers[/B].[*] Open a command prompt on the domain controller and enter [B]gpupdate[/B] and press ENTER.[*] When the client systems restart, the Firewall client software will install automatically.[/LIST]
[B]Connect the Corporate Network Clients to Resources on the Network Services Segment and the Internet[/B]

Now the clients on the Corpnet ISA firewall Network are ready to connect to resources on the network services segment and the Internet.
Open the Web browser on the client and go to [URL="http://www.isaserver.org/"]www.isaserver.org[/URL]. You’ll see log file entries on the edge ISA firewall that appear similar to those in the figure below.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0261131368723988.jpg[/IMG]
[B]Figure 13[/B][/INDENT]Now open a share on the File server on the network services segment. You’ll see entries like those in the figure below.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0281131368724145.jpg[/IMG]
[B]Figure 14[/B]
[B] [CENTER]

[URL="http://www.amazon.com/exec/obidos/ASIN/1931836191/ref%3Dnosim/searchbyisbn/wwwshindernet-20/103-5455432-1772662"]
[/URL][/CENTER]
[/B][/INDENT][B]Summary[/B]

In this article series on configuring a network services segment using an ISA firewall, we began with an in depth discussion on network perimeters and how to design a functional network services segment via perimeterization. The following articles provided detailed concepts and step by step details on how to configure the edge and network services perimeter ISA firewall to support secure connections from hosts located on the corporate network outside the perimeter and to selected Exchange Server services from Internet hosts.


[/LEFT]