Publishing Servers on a ISA Server 2004 Firewall Public Address DMZ Segment v1.01
[LEFT][CODE]http://www.isaserver.org/articles/2004pubdmzservers.html[/CODE]
This article describes how to publish a public address DMZ host using Access Rules. This method allows you to use the public addresses your servers have already been using and leverage the full stateful application layer filtering power of the ISA Server 2004 firewall. Unlike traditional packet filter based firewalls (PIX, Netscreen, SonicWall, etc.), the ISA Server 2004 firewall performs stateful filtering and stateful application layer inspection on all communications moving through the firewall. Check out this article for a full discussion and step by step details on how ISA 2004 firewalls accomplish this amazing feat
One of the most significant improvements in the ISA Server 2004 firewall over the old ISA Server 2000 firewall is multinetworking. Multinetworking refers to how the ISA Server 2004 firewall sees the world. Unlike the ISA Server 2000 firewall, which saw the world as "trusted versus untrusted (LAT versus non-LAT), the ISA Server 2004 firewall sees all networks as untrusted and applies firewall policy to all connections made through the ISA Server 2004 firewall. This includes hosts connecting through a VPN remote access client or VPN gateway connection.
[CENTER][FONT=Verdana][I][FONT=Verdana][SIZE=2][B][B][URL="http://www.amazon.com/exec/obidos/ASIN/1931836191/ref=nosim/searchbyisbn/wwwshindernet-20"]
[/URL][/B][/B][/SIZE][/FONT][/I][/FONT][/CENTER]
ISA Server 2004 multinetworking allows you to connect multiple interfaces (or multiple virtual interfaces using VLAN tagging) and have complete control over the traffic that moves between networks connected by the ISA Server 2004 firewall. This is in stark contrast to the ISA Server 2000 networking model, where traffic moving between internal networks was not exposed to firewall policy and you had to create a "poor man’s DMZ" using RRAS packet filters.
In this article we’ll examine how to publish hosts on a [I]public [/I]address DMZ segment. You might remember that ISA Server 2000 required the use of public addresses on a DMZ segment. The ISA Server 2000 DMZ segment had to use public addresses; you didn’t have the option to use private addresses because the ISA Server 2000 firewall routed (instead of NAT’d) connections to the trihomed DMZ segment using simple stateful packet filters (akin to the PIX). In contrast, the ISA Server 2004 firewall allows you to route between the Internet and a DMZ segment, or NAT between the Internet and DMZ segment. In fact, the ISA Server 2004 firewall allows you to decide how you want connections to be routed between any two networks: route or NAT.
Using public addresses is sometimes necessary if you have an established DMZ segment with multiple hosts using public addresses and you do not wish to change the addressing scheme because of overhead involved with making the appropriate public DNS changes. You still want to use the current IP addressing scheme on the servers so that Internet hosts reach the DMZ severs using the same IP addresses (actually, same DNS mappings) used previously. You can do this with the ISA Server 2004 firewall by configuring a route relationship between the Internet and the DMZ segment containing the servers you want to "publish".
Note that I put [I]publish[/I] in quotes. ISA Server 2004 firewall policy provides two methods you can use to control traffic moving through the firewall: Access Rules and Publishing Rules. Access Rules can participate in a route or NAT relationship. Publishing Rules always NAT the connection, even if you’re using a public address segment and have a route relationship between the source and destination host.
If it sounds a bit confusing, it is. It’s especially confusing if you’re accustomed to the ISA Server 2000 way of doing things, where you always had to NAT between untrusted and trusted hosts. Before we get into the specifics of how to publish servers on a public address segment, let’s take a look at some of the aspects of the new ISA Server 2004 networking model.
The figure below shows the sample network we’ll use in the how-to portion of this article. The figure shows a route relationship between the Internet and the DMZ segment. When the PocketPC PDA client connects to the server on the DMZ segment, the name it uses to establish the connection resolves to the actual IP address of the DMZ host, which in this case is 172.16.0.2. The route relationship allows us to do this and preserve the existing DNS records mapping the DMZ host to its actual IP address. ISA Server 2004 Access Rules are used to make the DMZ host available to Internet clients.
[INDENT] [IMG]http://www.isaserver.org/img/upl/Image26261087812865880.gif[/IMG][/INDENT]However, you can also use publishing rules to make the public address DMZ host available to Internet users. In this case, the PocketPC PDA host on the Internet uses an IP address on the [I]external interface [/I]of the ISA Server 2004 firewall to access the DMZ host. Note that the DMZ host still has a public address. Even though we are using public IP addresses, NAT is performed because we’re using a publishing rule. This allows the Internet host to connect to the IP address on the external interface of the ISA Server 2004 firewall and effectively [I]hides[/I] the IP address of the DMZ host. This [I]NAT hiding[/I] is a common security measure for publicly available servers.
[INDENT] [IMG]http://www.isaserver.org/img/upl/Image26271087812913098.gif[/IMG][/INDENT]Note in the figures that IP address used by the DMZ host for the DNS server address. The address [B]172.16.0.1[/B] is the IP address of the DMZ interface. The reason why we use this IP address instead of the actual DNS server address is that we’re publishing the DNS server on the Internal network. The DNS Server Publishing Rule listens on the IP address on the DMZ interface. You’ll see the details of this configuration later in this article.
One of the major drawbacks of ISA Server 2000 Web publishing scenarios was that you always received the IP address of the ISA Server 2000 firewall in the published Web servers’ log files. This was problematic for organizations that had already invested large sums of money in log analysis and reporting software that pulled information from the Web server’s logs. ISA Server 2004 fixes this problem and allows you to choose to pass the original client IP address to published Web server, or to use the ISA Server 2004 firewall’s IP address. This is true for publishing rules on public and private address DMZs for all publishing rules: both Web and Server Publishing.
The table below describes the ISA Server 2004 behavior for allowing remote access to DMZ segments using public address and private addresses.
[B] Table 1: Remote Access to DMZ Server using Private v. Public Addresses, NAT v. Route, Access Rules, and Publishing Rules
[/B] [FONT=Verdana][/FONT][CENTER][FONT=Verdana][B]Addressing Scheme – [/B][/FONT][/CENTER]
[CENTER][FONT=Verdana][B]Route Relationship – Rule Type[/B][/FONT][/CENTER]
[FONT=Verdana][/FONT][CENTER][FONT=Verdana][B]Result and Explanation[/B][/FONT][/CENTER]
[FONT=Verdana]Public Address DMZ with Route Relationship using Access Rules [/FONT] [FONT=Verdana]This configuration allows you connect to your DMZ hosts using their actual public addresses. The log files on the published servers will show the original source IP address of the remote host. The exception is when you create an Access Rule to connect to an HTTP server on the DMZ segment. In this case, the ISA Server 2004 firewall’s IP address will appear as the source address. This can be corrected by disabling the Web Proxy filter on the rule.[/FONT] [FONT=Verdana]Public Address DMZ with Route relationship using Publishing Rules*[/FONT] [FONT=Verdana]This configuration requires that you connect to the published DMZ host via an IP address bound to the external interface of the ISA Server 2004 firewall. Connections are not made to the actual IP address of the DMZ host and your public DNS records may need to be changed to reflect this fact. Source IP address will be that of the ISA Server 2004 firewall, unless you configure the Server and Web Publishing Rules for forward the original source IP address (you have a choice of forwarding the original client’s source IP address or the ISA Server 2004 firewall’s IP address to the published server)[/FONT] [FONT=Verdana]Public Address DMZ with NAT relationship using Access Rules [/FONT] [FONT=Verdana]This configuration requires that you connect to the published DMZ host via an IP address bound to the external interface of the ISA Server 2004 firewall. Connections are not made to the actual IP address of the DMZ host and your public DNS records may need to be changed to reflect this fact. Source IP address will be that of the ISA Server 2004 firewall, unless you configure the Server and Web Publishing Rules for forward the original source IP address (you have a choice of forwarding the original client’s source IP address or the ISA Server 2004 firewall’s IP address to the published server). The result is that this setup is very similar to the last option[/FONT] [FONT=Verdana]Public Address DMZ with NAT relationship using Publishing Rules*[/FONT] [FONT=Verdana]This configuration requires that you connect to the published DMZ host via an IP address bound to the external interface of the ISA Server 2004 firewall. Connections are not made to the actual IP address of the DMZ host and your public DNS records may need to be changed to reflect this fact. Source IP address will be that of the ISA Server 2004 firewall, unless you configure the Server and Web Publishing Rules for forward the original source IP address (you have a choice of forwarding the original client’s source IP address or the ISA Server 2004 firewall’s IP address to the published server). Sound familiar?[/FONT] [FONT=Verdana]Private Address DMZ with NAT relationship using Publishing Rules*[/FONT] [FONT=Verdana]This configuration requires that you connect to the published DMZ host via an IP address bound to the external interface of the ISA Server 2004 firewall. Connections are not made to the actual IP address of the DMZ host and your public DNS records may need to be changed to reflect this fact. Source IP address will be that of the ISA Server 2004 firewall, unless you configure the Server and Web Publishing Rules for forward the original source IP address (you have a choice of forwarding the original client’s source IP address or the ISA Server 2004 firewall’s IP address to the published server). Yep, it’s the same as the last two.[/FONT][FONT=Verdana] [/FONT][FONT=Verdana]* Note that in all publishing rule configurations, the connection is NAT’ed. In no circumstance is a connection routed when you use a Web or Server Publishing Rule.[/FONT]
[FONT=Verdana]There are some interesting results based on whether the Web Proxy filter is enabled on an Access Rule. We’ll explore this behavior later in this article.[/FONT]
[FONT=Verdana]Before finishing out this discussion, I should mention that you do lose a amount of security for certain scenarios when you decide to use Access Rules instead of publishing rules to allow access to your DMZ hosts, to the extent where the ISA Server 2004 provides little more security than a PIX or Netscreen device. Reasons why you might want to use publishing rules include:[/FONT]
[LIST][FONT=Verdana][*]Web publishing rules allow you to prevent users from using IP addresses instead of FQDNs to access resources on the DMZ host. Many worms attack servers based on IP addresses, but rarely use a FQDN[*]Web publishing rules allow you to configure custom Web listeners, which provide features such as Exchange Forms-based authentication, delegation of basic authentication and RSA SecurID authentication.[*]Web publishing rules allow you to perform SSL to SSL bridging. This prevents attackers from hiding exploits inside an SSL tunnel. When using SSL to SSL bridging, the ISA Server 2004 firewall "unwraps" the SSL tunnel, exposes the connection to the ISA Server 2004 firewall’s deep stateful application layer inspection mechanisms, and drops connections containing exploits and suspicious characteristics. Connections deemed to be safe are then re-encrypted and sent to the published Web server via a second SSL link, which is created between the ISA Server 2004 firewall and the published Web server.[*]Server publishing rules expose incoming connections to the application layer filters dedicated to protecting specific services. Examples include the SMTP filter that blocks buffer overflow attacks, the DNS filter which blocks a number of DNS exploits, and the POP3 filter which blocks POP3 buffer overflows. If you use Access Rules to publish the public address DMZ hosts, the application layer filters will not protect you against these exploits.[*]If you publish a public address Web server on a DMZ segment using Access Rules, you are still protected by the HTTP security filter. The HTTP security filter provides very deep application layer inspection for all HTTP communications moving through the ISA Server 2004 firewall. The HTTP security filter allows you granular control and is configurable on a per-rule basis, so that you’re not stuck with a single HTTP security policy for all the rules on the ISA Server 2004 firewall. This is a quantum leap ahead of the URLScan method of filtering HTTP communications through the firewall (URLScan was used in ISA Server 2000 for HTTP stateful inspection).[/FONT][/LIST]
[FONT=Verdana]The remainder of this article will describe how to publish a public address DMZ host using Access Rules. This method allows you to continue to use the public addresses your servers have been using, but continue to leverage the full stateful application layer filtering power of the ISA Server 2004 firewall. Unlike traditional packet filter based firewalls (PIX, Netscreen, SonicWall, etc.), the ISA Server 2004 firewall performs stateful filtering and stateful application layer inspection on all communications moving through the firewall. This provides a higher level of protection and control than any other firewall on the market.[/FONT]
[CENTER][FONT=Verdana][FONT=Verdana][I][FONT=Verdana][SIZE=2][B][B][URL="http://www.amazon.com/exec/obidos/ASIN/1931836191/ref=nosim/searchbyisbn/wwwshindernet-20"]
[/URL][/B][/B][/SIZE][/FONT][/I][/FONT][/FONT][/CENTER]
[FONT=Verdana]To accomplish our goal, you’ll need to perform the following steps:[/FONT]
[LIST][FONT=Verdana][*]Configure the routing table on the upstream router[*]Configure the network adaptors[*]Install the ISA Server 2004 firewall software[*]Install and configure the IIS WWW and SMTP services on the DMZ server[*]Create the DMZ network[*]Create the Network Rules Between the DMZ and External Network and for the DMZ and Internal Network[*]Create an Server Publishing Rule allowing DNS from DMZ to Internal[*]Create an Access Rule allowing DNS from Internal to External[*]Create an Access Rule allow HTTP from External to DMZ[*]Create an Access Rule allowing SMTP from External to DMZ[*]Test the Access Rules from External to DMZ[*]Change the Access Rule allowing External to DMZ by disabling the Web Proxy filter[/FONT][/LIST]
[B]Configure the Routing Table on the Upstream Router[/B]
[FONT=Verdana] The most common problem I’ve seen with ISA firewall admins who put together public address DMZ segments relates to the routing table entries on the upstream router. When you create a public address DMZ segment, you need to subnet your public block and assign one of the subnets to the DMZ segment. You can then bind the first valid address of a subnetted block to the DMZ interface and the first valid address of another subnetted block to the public interface.
That’s where many ISA firewall admins stop and that’s where they run into problems. You have to configure the upstream router with a route to the DMZ segment. You do this by configuring the router to use the IP address on the external interface of the ISA Server 2004 firewall as the gateway address for the DMZ segment’s network ID. If this routing table entry is missing on the upstream router, then no primary incoming connections, and no responses to incoming connections, to and from the DMZ segment will work.
In the lab network we’re using for the examples in this article, the external network host is on the same network ID as the external interface of the ISA Server 2004 firewall, which is 192.168.1.0/24. The external IP address on the ISA Server 2004 firewall is [B]192.168.1.70[/B] and the external host will use an IP address assigned in the same network ID. The DMZ segment uses the network ID [B]172.16.0.0/16[/B]. Therefore, on the Windows XP external network host we use in this article, I configured a routing table entry to tell it to use the external IP address of the ISA Server 2004 firewall to reach network ID [B]172.16.0.0/16[/B]. Specially, I did:
[B] route add 172.16.0.0 MASK 255.255.0.0 192.168.1.70
[/B] Note that this example does not use a subnet of a public address block. In your production environment, you would subnet your public address block and create a routing table entry for your DMZ segment’s subnetted block on your router upstream from the ISA Server 2004 firewall. This implies you have control over the upstream router, which makes public address DMZ segments a moot point for hobbyist ISP accounts. However, there’s no reason why you can’t create private address DMZs with a hobbyist ISP account.
[/FONT] [B]Configure the Network Adapters[/B]
[FONT=Verdana] [/FONT][FONT=Verdana]Network adapter configuration was always a bone of contention for ISA Server 2000 admins and I anticipate it will continue to be for ISA Server 2004 admins. There are a number of reasons for this, the primary issue being whether or not you host your own DNS services.[/FONT]
[FONT=Verdana]DNS is a critical issue for the ISA Server 2004 firewall because the firewall can perform proxy name resolution for Web Proxy and Firewall clients. The ISA Server 2004 firewall uses DNS settings on its NICs to query the appropriate DNS server. If you have the incorrect DNS server configuration, you can experience either slow name resolution, or no name resolution at all, which gives the end user the impression that "the ISA Server 2004 firewall doesn’t work".[/FONT]
[FONT=Verdana]We can boil down the correct DNS configuration on the ISA Server 2004 firewall using the following guidelines:[/FONT]
[LIST][FONT=Verdana][*]If you have a DNS server on your internal network, you should configure that DNS server to support Internet host name resolution[*]If you choose to not allow your internal network DNS server to perform Internet host name resolution, you should consider putting a caching only DNS server on the ISA Server 2004 firewall, or on a DMZ segment[*]If you choose to put a DNS sever on a DMZ segment which is authoritative for your publicly accessible domains, do [B]not[/B] allow this DNS server to act as a DNS resolver. That is to say, your authoritative DNS server should only answer queries for the domains your host and return an error to users who try to resolve other names through that server[*]If you do not wish to host your own DNS servers and do not use DNS on the internal network, then configure the ISA Server 2004 firewall to use a public DNS server, such as your ISP’s DNS server. Note that this configuration will cause problems with name resolution for internal network hosts, and cause problems with Web Proxy and Firewall client connections. For this reason, you should choose another firewall for SOHO environments that do not have an established DNS infrastructure. However, if you have a SOHO environment and a DNS server, then ISA Server 2004 firewall is the ideal firewall to protect your company’s assets[*]Never EVER put a public DNS server address on the same NIC that has your private DNS server address configured on it.[*]The DNS server address should be configured on the [I]top listed [/I]interface in the [B]Network and Dial-up Connections[/B] window. For example, if you have a trihomed ISA Server 2004 firewall and a DMZ interface, an Internal interface and a public interface, the Internal NIC should be on the top of the list and the DNS server IP address should be configured on that interface. This is true regardless if you use an Internal DNS server, a DMZ DNS server or a public DNS server, such as your ISP’s DNS server[*]If you don’t understand these principles, ask someone who does. DNS settings are critical and if the DNS configuration on your ISA Server 2004 firewall is incorrect, you [I]will [/I]experience connectivity problems that are difficult to troubleshoot and it will give you the false impression that the ISA Server 2004 firewall "does not work".[/FONT][/LIST]
[FONT=Verdana]Bottom line: get your DNS house in order before publishing your public address DMZ servers to the Internet.[/FONT]
[CENTER][FONT=Verdana][FONT=Verdana][I][FONT=Verdana][SIZE=2][B][B][URL="http://www.amazon.com/exec/obidos/ASIN/1931836191/ref=nosim/searchbyisbn/wwwshindernet-20"]
[/URL][/B][/B][/SIZE][/FONT][/I][/FONT][/FONT][/CENTER]
[B]Install the ISA Server 2004 Firewall Software[/B]
[FONT=Verdana] After the DNS situation is handled and the network interfaces on the ISA Server 2004 firewall are properly configured, you’re ready to install the ISA Server 2004 firewall software. While I hate to tell people "please see blah blah blah" for instructions on how to do something (because you end up wasting a lot of time trying to figure out how the information at blah blah blah solves the specific problem at hand), I’m am going to refer you to another article on how to install the ISA Server 2004 firewall. You wont’ have to wade through a bunch of stuff you don’t care about, so don’t worry.
Just head on over to [URL="http://www.isaserver.org/articles/isa2004beta2.html"][U][COLOR=#800080]http://www.isaserver.org/articles/isa2004beta2.html[/COLOR][/U][/URL] for installation instructions. Note that this article is based on the Beta2 version of the product and the final interface will look at bit different. However, there should be no significant differences in the actual procedures you carry out when you install the ISA Server 2004 firewall software.
[/FONT] [B]Install and Configure the IIS WWW and SMTP Services on the DMZ Server[/B]
[FONT=Verdana] In this article we will place a Windows Server 2003 machine in the public address DMZ. The machine will have the IIS 6.0 WWW service (W3SVC) installed and the IIS 6.0 SMTP service. We’ll publish both of these services to the Internet using Access Rules. In your production network, you’ll install and configure the services you require, which might include a front-end Exchange Serve publishing OWA, OMA, ActiveSync, RPC over HTTP and other services.
The host on the DMZ segment uses an IP address valid for your subnetted block used for the DMZ. The published DMZ host uses the IP address of the DMZ interface on the ISA Server 2004 firewall as its default gateway. The DMZ host does [I]not[/I] use the Internal network IP address as its default gateway because it does not have access to addresses on the Internal network unless we give it access, and we’re not going to do that.
The DNS server address on the DMZ host’s NIC will be the IP address of the DMZ interface on the ISA Server 2004 firewall. We use this configuration because we will configure a NAT relationship between the DMZ segment and the Internal network and a Server Publishing Rule that publishes the DNS server on the DMZ interface’s IP address.
The internal network DNS server is configured to resolve Internet host names. This is useful if you want to use the SMTP server on the DMZ segment as an outbound SMTP relay. The SMTP relay needs to be able to resolve the MX domain name for each outgoing mail message and it can use the DNS server on the Internal network to get this done.
[/FONT] [B]Create the DMZ Network[/B]
[FONT=Verdana] [/FONT][FONT=Verdana]With the DMZ server in place, we can now get in front of the ISA Server 2004 management console and create the rules to make it all happen. The first step is to create the DMZ Network. The ISA Server 2004 firewall needs to know the IP addresses used on the network and the route relationship it should use when connecting to any other network. In our current example, the DMZ network will be named [B]DMZ[/B] and we will assign the entire IP address range for its network ID to the network. On your production network, you would include all the IP addresses in the subnetted block you created for the DMZ segment.[/FONT]
[FONT=Verdana][/FONT][FONT=Verdana][B]IMPORTANT: [/B]
You may have noticed that ISA Server 2004 comes with several Network Templates that purportedly simplify configuration of the trihomed DMZ network. However, I recommend against using these templates because they make assumptions about the route relationship between your networks and require you to configure firewall access policies that are not very well documented, nor are they very well understood by the fledgling ISA Server 2004 admin. I’ve already seen a large number of network configuration and troubleshooting issues related to using the Network Templates. These problems would have been avoided by manually configuring the firewall. By avoiding the use of Network Templates, you will assure that you have a secure configuration and that your firewall configuration and Access Policies are precisely what you intend them to be.[/FONT]
[FONT=Verdana]Perform the following steps to create the DMZ network:[/FONT]
[LIST=1][FONT=Verdana][*]In the [B]Microsoft Internet Security and Acceleration Server 2004[/B] management 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 of the console. On the [B]Tasks[/B] tab, 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 rule in the [B]Network name[/B] text box. In this example, we’ll name the network [B]DMZ[/B]. Click [B]Next[/B].[*]On the [B]Network Type[/B] page, select the [B]Perimeter Network [/B]option. Click [B]Next[/B].[/FONT][/LIST]
[INDENT] [FONT=Verdana][IMG]http://www.isaserver.org/img/upl/Image26281087812961411.gif[/IMG][/FONT][/INDENT]
[LIST=1][FONT=Verdana][*]On the [B]Network Addresses[/B] page, click the [B]Add Adapter[/B] button.[*]In the [B]Select Network Adapters[/B] dialog box, select the [B]DMZ[/B] network interface and then put a checkmark in the interface’s checkbox. Note that you can put a checkmark in the checkbox without selecting the interface first. However, if you do not select the interface, you will not see the correct [B]Network Interface Information[/B] in the frame at the bottom of the dialog box. Click [B]OK[/B].[/FONT][/LIST]
[INDENT] [FONT=Verdana][IMG]http://www.isaserver.org/img/upl/Image26291087813019333.gif[/IMG][/FONT][/INDENT]
[LIST=1][FONT=Verdana][*]Click [B]Next[/B] on the [B]Network Addresses[/B] page.[*]Review your settings on the [B]Completing the New Network Wizard[/B] page and click [B]Finish[/B].[/FONT][/LIST]
[B]Create the Network Rules Between the DMZ and External Network and for the DMZ and Internal Network[/B]
[FONT=Verdana] [/FONT][FONT=Verdana]Now that the DMZ network is defined, the next step is to configure the route relationships between the DMZ network, the Internal network and the Internet (which is the External network, which is defined as any network for which you haven’t defined a network). [/FONT]
[FONT=Verdana]In our example, we want a route relationship between the DMZ network and the Internet, and a NAT relationship between the DMZ network and the Internal network. This allows us to use Access Rules to allow external hosts access to the DMZ segment and a server publishing rule to hide the IP address of the DNS server on the Internal network. Note that even if we used a route relationship between the DMZ and the Internal network, we could still create a Server Publishing Rule to allow the DMZ host access to the DNS server on the Internal network. Its important that we use a Server Publishing Rule instead of a Access Rule so that the DNS filter can protect the DNS server on the Internal network.[/FONT]
[FONT=Verdana]Perform the following steps to create the Network Rule controlling the route relationship between the DMZ network and the Internet:[/FONT]
[LIST=1][FONT=Verdana][*]On the [B]Networks [/B]node in the left pane of the console, click on the [B]Network Rules[/B] tab in the Details pane. Click the [B]Create a New Network Rule[/B] link on the [B]Tasks[/B] tab in 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 Network Rule[/FONT][B][FONT=Verdana]DMZß à External[/FONT][/B][FONT=Verdana]. 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 on the [B]DMZ[/B] network. Click [B]Close[/B].[*]Click [B]Next[/B] on the [B]Network Traffic Sources[/B] page.[*]On the [B]Network Traffic Destinations[/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 on [B]External[/B]. Click [B]Close[/B].[/FONT][/LIST]
[FONT=Verdana][SIZE=2] [/SIZE][/FONT][INDENT] [FONT=Verdana][SIZE=2][IMG]http://www.isaserver.org/img/upl/Image26301087813068192.gif[/IMG][/SIZE][/FONT][/INDENT]
[LIST=1][FONT=Verdana][SIZE=2][*]Click [B]Next[/B] on the [B]Network Traffic Destinations[/B] page.[*]On the [B]Network Relationship [/B]page, select the [B]Route[/B] option and click [B]Next[/B].[/SIZE][/FONT][/LIST]
[FONT=Arial][SIZE=2][FONT=Verdana][SIZE=2] [/SIZE][/FONT][/SIZE][/FONT][INDENT] [FONT=Arial][SIZE=2][FONT=Verdana][SIZE=2][IMG]http://www.isaserver.org/img/upl/Image26311087813091536.gif[/IMG][/SIZE][/FONT][/SIZE][/FONT][/INDENT]
[LIST=1][FONT=Arial][SIZE=2][FONT=Verdana][SIZE=2][*]Review your settings on the [B]Completing the New Network Wizard[/B] page and click [B]Finish[/B].[/SIZE][/FONT][/SIZE][/FONT][/LIST]
[FONT=Arial][SIZE=2][FONT=Verdana][SIZE=2]The next step is to create the route relationship between the DMZ Network and the Internal Network. In this case, we’ll use the NAT route relationship between DMZ and Internal network.[/SIZE][/FONT][/SIZE][/FONT]
[FONT=Arial][SIZE=2][FONT=Verdana][SIZE=2]Perform the following steps to create the NAT route relationship between DMZ and Internal networks:[/SIZE][/FONT][/SIZE][/FONT]
[LIST=1][FONT=Arial][SIZE=2][FONT=Verdana][SIZE=2][*]On the [B]Networks [/B]node in the left pane of the console, click on the [B]Network Rules[/B] tab in the Details pane. Click the [B]Create a New Network Rule[/B] link on the [B]Tasks[/B] tab in 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 Network Rule[/SIZE][/FONT][FONT=Arial][SIZE=2][B][FONT=Verdana]DMZ[/FONT][FONT=Verdana][SIZE=2]ß à Internal[/SIZE][/FONT][/B][/SIZE][/FONT][/SIZE][/FONT][FONT=Verdana][SIZE=2]. Click [B]Next[/B].[/SIZE][/FONT][FONT=Verdana][SIZE=2] [*]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 on the [B]Internal[/B] network. Click [B]Close[/B].[*]Click [B]Next[/B] on the [B]Network Traffic Sources[/B] page.[*]On the [B]Network Traffic Destinations[/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 on [B]DMZ[/B]. Click [B]Close[/B].[*]Click [B]Next[/B] on the [B]Network Traffic Destinations[/B] page.[*]On the [B]Network Relationship [/B]page, select the [B]Route[/B] option and click [B]Next[/B].[/SIZE][/FONT][/LIST]
[INDENT] [FONT=Verdana][SIZE=2][IMG]http://www.isaserver.org/img/upl/Image26321087813129161.gif[/IMG][/SIZE][/FONT][/INDENT]
[LIST=1][FONT=Verdana][SIZE=2][*]Review your settings on the [B]Completing the New Network Wizard[/B] page and click [B]Finish[/B].[/SIZE][/FONT][/LIST]
[B]Create Server Publishing Rule allowing DNS from DMZ to Internal[/B]
[FONT=Verdana] [/FONT][FONT=Verdana]The DMZ host may need to resolve Internet host names. This is the case whenever the DMZ host needs to establish new outbound connections to servers on the Internet based on the destination host name. An example would be when you have an SMTP relay on the DMZ segment that’s used to relay outbound mail for your organization.[/FONT]
[FONT=Verdana]We use a Server Publishing Rule in this example so that the DNS filter’s protection is applied to connections from the DMZ host to the DNS server on the Internal network.[/FONT]
[FONT=Verdana]Perform the following steps to create the Server Publishing Rule:[/FONT]
[LIST=1][FONT=Verdana][*]In the [B]Microsoft Internet Security and Acceleration Server 2004[/B] management console, click the [B]Firewall Policy[/B] node. In the Task Pane, click the [B]Tasks[/B] tab and then click the [B]Create 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 Internal DNS Server[/B]. Click [B]Next[/B].[*]On the [B]Select Server[/B] page, enter the IP address of the DNS server on the Internal network. In this example, the IP address of the Internal Network DNS server is [B]10.0.0.2[/B], so we’ll enter that into the text box. Click [B]Next[/B].[*]On the [B]Select Protocol[/B] page, select the [B]DNS Server[/B] protocol from the [B]Selected protocol[/B] list. Click [B]Next[/B].[/FONT][/LIST]
[INDENT] [FONT=Verdana][IMG]http://www.isaserver.org/img/upl/Image26331087813155973.gif[/IMG][/FONT][/INDENT]
[LIST=1][FONT=Verdana][*]On the [B]IP Addresses[/B] page, put a checkmark in the [B]DMZ[/B] checkbox. This is the interface on which the Server Publishing Rule will listen for incoming connection requests to the Internal network DNS server. Click [B]Next[/B].[/FONT][/LIST]
[INDENT] [FONT=Verdana][IMG]http://www.isaserver.org/img/upl/Image26341087813199286.gif[/IMG][/FONT][/INDENT]
[LIST=1][FONT=Verdana][*]Review your settings on the [B]Completing the New Server Publishing Rule [/B]page and click [B]Finish[/B].[/FONT][/LIST]
[B]Create an Access Rule allowing DNS from Internal to External[/B]
[FONT=Verdana] [/FONT][FONT=Verdana]The Internal network DNS server needs to be able to query Internet DNS server to resolve Internet host names. We can create a DNS Access Rule that will allow the Internal network DNS server access to Internet DNS servers using the DNS protocol.[/FONT]
[FONT=Verdana]Perform the following steps to create the DNS Access Rule for the DNS server:[/FONT]
[LIST=1][FONT=Verdana][*]In the [B]Microsoft Internet Security and Acceleration Server 2004[/B] management console, click the [B]Firewall Policy[/B] node in the left pane of the console.[*]Click the [B]Tasks[/B] tab in the Task Pane and then click the [B]Create New Access Rule [/B]link.[*]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 call the rule [B]Outbound DNS Internal DNS Server[/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] entry from the [B]This rule applies to[/B] list. Click the [B]Add[/B] button.[*]In the [B]Add Protocols[/B] dialog box, 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]New[/B] button. Click the [B]Computer[/B] entry.[*]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 enter the name [B]Internal DNS Server[/B]. In the [B]Computer IP Address[/B] text box, enter the IP address of the Internal DNS server. In this example, the IP address is [B]10.0.0.2[/B], so we’ll enter that IP address. Click [B]OK[/B].[*]Click the [B]Computers[/B] folder and double click the [B]Internal DNS Server[/B] entry. Click [B]Close[/B].[*]On the [B]Access Rule Sources[/B] page, click [B]Next[/B].[*]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] entry and 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]User Sets[/B] and click [B]Next[/B].[*]Review the settings on the [B]Completing the New Access Rule Wizard[/B] page and click [B]Finish[/B].[/FONT][/LIST]
[B]Create an Access Rule allow HTTP from External to DMZ[/B]
[FONT=Verdana] [/FONT][FONT=Verdana]The next step is to create an Access Rule that allows HTTP from the External network to the DMZ host. While you do not benefit from the full firewall feature set provided by a Web publishing rule, this option allows you to expose the actual IP address of the Web server to the Internet and the security provided by the HTTP Security Filter still applies to the Access Rule. The basic configuration of the HTTP Security filter provides a good level of protection and you can customize the HTTP Security Filter to provide an enhance level of security to your Access Rule published Web server.[/FONT]
[FONT=Verdana]Perform the following steps to publish your DMZ Web server using an Access Rule:[/FONT]
[LIST=1][FONT=Verdana][*]In the [B]Microsoft Internet Security and Acceleration Server 2004[/B] management console, click on the [B]Firewall Policy[/B] node in the left pane of the console and then click the [B]Create a New Access Rule[/B] link in the [B]Tasks[/B] tab of the Task Pane.[*]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]Inbound to DMZ Web Server[/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, click the select the [B]Selected protocols[/B] option from the [B]This 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 the [B]HTTP[/B] entry. Click [B]Close[/B].[/FONT][/LIST]
[INDENT] [FONT=Verdana][IMG]http://www.isaserver.org/img/upl/Image26351087813249895.gif[/IMG][/FONT][/INDENT]
[LIST=1][FONT=Verdana][*]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]External[/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]New[/B] menu then click the [B]Computer [/B]entry.[*]In the [B]New Computer Rule Element[/B] dialog box, enter a name for the DMZ Web server in the [B]Name[/B] text box. In this example we’ll use [B]DMZ Web Server[/B]. Enter the IP address of the DMZ Web server in the[B] Computer IP Address[/B] text box. In this example, the IP address of the DMZ Web server is [B]172.16.0.2[/B], so we’ll enter that value into the text box. Click [B]OK[/B].[/FONT][/LIST]
[INDENT] [FONT=Verdana][IMG]http://www.isaserver.org/img/upl/Image26361087813286239.gif[/IMG][/FONT][/INDENT]
[LIST=1][FONT=Verdana][*]In the [B]Add Network Entities[/B] dialog box, click the [B]Computers[/B] folder. Double click the [B]DMZ Web Server[/B] entry. 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].[*]Review your settings on the [B]Completing the New Access Rule Wizard[/B] page and click [B]Finish[/B].[/FONT][/LIST]
[B]Create an Access Rule allowing SMTP from External to DMZ[/B]
[FONT=Verdana] [/FONT][FONT=Verdana]Now that the Web server is published, we’ll create another rule that allows inbound access to the SMTP server on the DMZ network. Again, we’ll use an Access Rule. Note that when we use an Access Rule instead of an Server Publishing Rule, we will not benefit from the protection we get from SMTP filter.[/FONT]
[FONT=Verdana]Perform the following steps to create the Access Rule allow inbound access to the SMTP server:[/FONT]
[LIST=1][FONT=Verdana][*]In the [B]Microsoft Internet Security and Acceleration Server 2004[/B] management console, click on the [B]Firewall Policy[/B] node in the left pane of the console and then click the [B]Create a New Access Rule[/B] link in the [B]Tasks[/B] tab of the Task Pane.[*]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]Inbound to DMZ SMTP Server[/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, click the select the [B]Selected protocols[/B] option from the [B]This 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 the [B]SMTP [/B]entry. Click [B]Close[/B].[/FONT][/LIST]
[INDENT] [FONT=Verdana][IMG]http://www.isaserver.org/img/upl/Image26371087813390130.gif[/IMG][/FONT][/INDENT]
[LIST=1][FONT=Verdana][*]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]External [/B]network. 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]Computers [/B]folder. Double click the [B]DMZ Web Server [/B]entry. 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].[*]Review your settings on the [B]Completing the New Access Rule Wizard[/B] page and click [B]Finish[/B].[*]Click [B]Apply [/B]to save the changes and update the firewall policy.[/FONT][/LIST]
[INDENT] [FONT=Verdana][IMG]http://www.isaserver.org/img/upl/Image26381087813423989.gif[/IMG][/FONT][/INDENT]
[LIST=1][FONT=Verdana][*]Click [B]OK[/B] in the [B]Apply New Configuration[/B] dialog box.[/FONT][/LIST]
[FONT=Verdana]Your Firewall Policy should look what what’s seen in the figure below.[/FONT]
[INDENT] [FONT=Verdana][IMG]http://www.isaserver.org/img/upl/Image26391087813447551.gif[/IMG][/FONT][/INDENT][B]Test the Access Rules from External to DMZ[/B]
[FONT=Verdana] [/FONT][FONT=Verdana]Now you’re ready to test the Access Rules. Perform the following steps to perform the tests:[/FONT]
[LIST=1][FONT=Verdana][*]Open the Web browser on the external host and enter the IP address of the DMZ Web server. In this case, the IP address of the DMZ Web server is [B]172.16.0.2[/B], so we’ll enter [B][url]http://172.16.0.2[/url][/B] in the Address bar of the browser and press ENTER.[*]The default Web page of the IIS Web site appears. In this example, we haven’t configured a special default Web page, so we’ll see the [B]Under Construction[/B] page. This demonstrates that the Access Rule allowing inbound access to the DMZ Web site worked correctly.[*]Now, let’s look at the Web site’s log file and see what shows up. Open the [B]Windows Explorer[/B] and navigate to [B]C:\WINDOWS\system32\LogFiles\W3SVC1[/B]. Double click on the log file that has today’s date on it. You’ll see something like what appears below. Note the highlighted entry. This indicates the source IP address as recorded in the Web server log. In this example, the source IP address is the IP address on the DMZ interface of the ISA Server 2004 firewall computer. This might not be what you suspected. The reason for this finding is that the Web Proxy Filter is automatically associated with the HTTP protocol. We’ll see how to disable the Web Proxy filter on the protocol later in this article.[/FONT][/LIST]
[FONT=Courier New][SIZE=2] #Software: Microsoft Internet Information Services 6.0
#Version: 1.0
#Date: 2004-06-18 05:47:14
2004-06-18 05:56:21 172.16.0.2 GET /iisstart.htm - 80 - 172.16.0.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) 200 0 0
2004-06-18 05:56:25 172.16.0.2 GET /pagerror.gif - 80 - 172.16.0.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) 200 0 0
[/SIZE][/FONT][FONT=Verdana] [/FONT]
[LIST=1][FONT=Verdana][*]Next, go to the Web Server on the DMZ segment and open the [B]Internet Information Services (IIS) Manager[/B] console from the [B]Administrative Tools[/B] menu in the [B]Start[/B] menu.[*]In the [B]Internet Information Services (IIS) Manager[/B] console, right click on the [B]Default Virtual SMTP Server[/B] and click [B]Properties[/B]. On the [B]General [/B]tab, put a checkmark in the [B]Enable Logging[/B] checkbox. Click [B]Apply[/B] and then click [B]OK[/B].[*]At the external host computer, open a command prompt. In the command prompt window, enter [B]telnet 172.16.0.2 25[/B] and press ENTER.[*]You’ll see the SMTP service banner appear. Enter [B]help[/B] and press ENTER. You’ll see a list of the commands supported by the SMTP server. Enter [B]quit[/B] to disconnect from the SMTP server.[/FONT][/LIST]
[INDENT] [FONT=Verdana][IMG]http://www.isaserver.org/img/upl/Image26401087813470676.gif[/IMG][/FONT][/INDENT]
[LIST=1][FONT=Verdana][*]Navigate to the [B]C:\WINDOWS\system32\LogFiles\SMTPSVC1[/B] on the DMZ host computer. Open the log file with today’s date. You’ll see something that looks like what you see below. Note the highlighted IP address. This is the address of the external host that made the inbound request to the DMZ SMTP server (which is at the same address as the DMZ Web server). In this case the original client IP address is preserved because the is no application filter proxying the connection and replacing the source IP address with the ISA Server 2004 firewall’s IP address.[/FONT][/LIST]
[FONT=Courier New] #Software: Microsoft Internet Information Services 6.0
#Version: 1.0
#Date: 2004-06-18 06:07:22
#Fields: time c-ip cs-method cs-uri-stem sc-status
06:07:22 192.168.1.187 QUIT - 240
[/FONT] [B]Test the DNS Rule from the DMZ to the Internal Network[/B]
[FONT=Verdana] [/FONT][FONT=Verdana]We demonstrated that the Access Rules controlling inbound access from the Internet to the DMZ host work correctly using the procedures in the previous section. The next step is to confirm that the Server Publishing Rule allowing the DMZ host access to the DNS server on the Internal network works correctly.[/FONT]
[FONT=Verdana]Perform the following steps to test the DNS Server Publishing Rule:[/FONT]
[LIST=1][FONT=Verdana][*]At the DMZ host open a command prompt. At the command prompt, enter [B]nslookup [url=http://www.hotmail.com]Sign In[/url][/B] and press ENTER.[*]You’ll see the results of the nslookup that look like the figure below. Note the first two entries triggered the [B]Publish Internal DNS Server[/B] rule and the subsequent entries triggered the [B]Outbound DNS Internal DNS Server [/B]rule. This shows that the DMZ host made a DNS query to the Internal network DNS server and the DNS server on the Internal network then queried Internet DNS servers to resolve the name.[/FONT][/LIST]
[INDENT] [FONT=Verdana][IMG]http://www.isaserver.org/img/upl/Image26411087813501176.gif[/IMG][/FONT][/INDENT]
[LIST=1][FONT=Verdana][*]You see entries like those in the figure below in the real time log monitor.[/FONT][/LIST]
[INDENT] [FONT=Verdana][IMG]http://www.isaserver.org/img/upl/Image26421087813855473.gif[/IMG][/FONT][/INDENT][B]Change the Access Rule Allowing External to DMZ by Disabling the Web Proxy Filter[/B]
[FONT=Verdana] [/FONT][FONT=Verdana]You may wish to see the original IP address of the external network host instead of the ISA Server 2004 firewall’s IP address when you publish the Web server using a Access Rule. You can accomplish this goal by disabling the Web Proxy filter. This can be done within the properties of the HTTP Access Rule you created earlier.[/FONT]
[FONT=Verdana]Perform the following steps to disable the Web Proxy filter:[/FONT]
[LIST=1][FONT=Verdana][*]In the [B]Microsoft Internet Security and Acceleration Server 2004[/B] management console, right click on the [B]Inbound to Web Server[/B] rule and click [B]Properties[/B].[*]In the [B]Inbound to Web Server Properties[/B] dialog box, click the [B]Protocols[/B] tab.[*]On the [B]Protocols[/B] tab, click the [B]HTTP [/B]entry in the [B]Protocols[/B] list and click the [B]Edit[/B] button.[/FONT][/LIST]
[INDENT] [FONT=Verdana][IMG]http://www.isaserver.org/img/upl/Image26431087813826301.gif[/IMG][/FONT][/INDENT]
[LIST=1][FONT=Verdana][*]In the [B]HTTP Properties[/B] dialog box, click the [B]Parameters[/B] tab. On the [B]Parameters[/B] tab, remove the checkmark from the [B]Web Proxy Filter[/B] checkbox in the [B]Application Filters[/B] frame. Click [B]Apply[/B] and then click [B]OK[/B].[*]Click [B]OK[/B] in the [B]Inbound to Web Server 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.[/FONT][/LIST]
[FONT=Verdana]Now let’s see what happens when we connect to the Web site again.[/FONT]
[LIST=1][FONT=Verdana][*]At the external client machine, open the Web browser and enter [B][url]http://172.16.0.2[/url][/B] in the Address bar and press ENTER.[*]The [B]Under Construction[/B] page appears. Hold down the CTRL key on the keyboard and click the [B]Refresh[/B] button in the browser’s button bar.[*]Return to the DMZ Web server and open the Web server’s WWW service’s log file. You’ll see something like what appears below. Note the highlighted IP addresses. The original IP address now appears in the log file.[/FONT][/LIST]
[FONT=Courier New][SIZE=2] #Software: Microsoft Internet Information Services 6.0
#Version: 1.0
#Date: 2004-06-18 07:42:37
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status
2004-06-18 07:42:37 172.16.0.2 GET /iisstart.htm - 80 - 192.168.1.187 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) 200 0 0
2004-06-18 07:42:37 172.16.0.2 GET /pagerror.gif - 80 - 192.168.1.187 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) 200 0 0
[/SIZE][/FONT][FONT=Verdana][SIZE=2] While disabling the Web Proxy filter on the HTTP protocol solves the problem of controlling the source IP address on the Access Rule published Web server, you do lose out on the Web Proxy filter for [I]all[/I] Web communications that aren’t made through the Web Proxy client configuration. This means that outbound connections from SecureNAT and Firewall clients will not be handled by the Web Proxy filter and they will not benefit from the Web Proxy cache and other features provided by the Web Proxy filter. In addition, there may be some unintended effects on Web Publishing rules. Note that I’m waffling a bit here, because I haven’t yet completed tested the side-effects of disabling the Web Proxy filter on the HTTP protocol :-).
An alternative is to create your own Protocol Definition that is defined as TCP 80 Outbound. You can use this custom Protocol Definition to publish the DMZ HTTP server host using an Access Rule. The big problem with this approach is that you do not have the protection of HTTP Security filter or the Web Proxy filter. In this scenario, you really [I]do[/I] have a PIX like firewall on your hands!
[CENTER][FONT=Verdana][I][FONT=Verdana][SIZE=2][B][B][URL="http://www.amazon.com/exec/obidos/ASIN/1931836191/ref=nosim/searchbyisbn/wwwshindernet-20"]
[/URL][/B][/B][/SIZE][/FONT][/I][/FONT][/CENTER]
[/SIZE][/FONT] [B]Conclusion[/B]
[FONT=Verdana] We’ve gone through a lot of stuff that took a lot of steps. What we ended up with was a public address trihomed DMZ segment hosting a server that is accessible via its public address. We accomplished this task by using Access Rules instead of Web and Server Publishing rules. The advantage of this configuration is that we didn’t not need change our public DNS configuration, which would have been the case if we used publishing rules. On the other hand, we lost out some security because Web and Server Publishing Rules make greater use of the ISA Server 2004 firewall’s sophisticated application layer filtering feature set.
[/FONT]
[/LEFT]
