Configuring Domain Members in a Back to Back ISA Firewall DMZ – Part 3: Configuring the DMZ Web Server and Front-end ISA Firewall

By /

Configuring Domain Members in a Back to Back ISA Firewall DMZ
Part 3: Configuring the DMZ Web Server and Front-end ISA Firewall
by Thomas W Shinder MD, MVP



Have Questions about the article? 

Ask at: http://tinyurl.com/qxpsn

If you would like to read the other parts in this article series please go to:

In the first two parts of this three part article series we discussed concepts in DMZ network design and deployment and went over the details of configuring the back-end ISA firewall.

In this article we’ll go through the following:

  • Configure a Routing Table Entry on the DMZ Server
  • Join the DMZ Server to the Domain located on the Default Internal Network behind the Back-end ISA Firewall
  • Configure the Front-end ISA Firewall’s Default Internal Network
  • Configure a Routing Table Entry on the Front-end ISA Firewall
  • Create an All Open Access Rule on the Front-end ISA Firewall
  • Create a Web Publishing Rule on the Front-end ISA Firewall
  • Test the Solution

Configure a Routing Table Entry on the DMZ Server

The default gateway on the DMZ Web server must be set for the internal interface of the front-end ISA firewall because the Web server needs to respond to connections from Internet hosts. In addition, the Web server may need to initiate connections to Internet hosts, such as the Microsoft Update Site. Note that this isn’t a hard and fast requirement, because if the Web server in the DMZ doesn’t need to initiate connections to Internet hosts, and you configure publishing rules on the front-end ISA firewall to replace the source IP address with the IP address of the ISA firewall, then you could get away with not making the default gateway on the DMZ Web server the front-end ISA firewall’s internal interface.

At the DMZ server, open a command prompt and enter the following:

route add –p 10.0.0.0 MASK 255.255.255.0 10.0.1.2

Where 10.0.0.0 is the network ID for the corporate network behind the ISA firewall, 255.255.255.0 is the subnet mask for that network ID, and 10.0.1.2 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.


Figure 1

Join the DMZ Server to the Domain Located on the Default Internal Network behind the Back-end ISA Firewall

The next step is to join the DMZ Web server to the corporate network domain. A key factor here is correct DNS configuration on the DMZ server’s network interface. The DMZ Web server must be able to find the domain controller on the corporate network. For this reason, we will use the IP address of the domain controller itself, which hosts an Active Directory integrated DNS server.

Perform the following steps to join the server to the domain (the procedure will vary with the OS the server is running; in this example the DMZ Web server is running Windows 2000).

  1. On the DMZ Web server, right click the My Computer icon on the desktop and click Properties.
  2. In the System Properties dialog box, click the Network Identification tab.
  3. On the Network Identification tab, click the Properties button.
  4. In the Identification Changes dialog box, select the Domain option and enter the FQDN for your domain. In this example, the corporate domain name is msfirewall.org so I will enter that name into the text box. Enter domain admin credentials in the authentication dialog box. Click OK in the dialog box welcoming you to the domain. Click OK in the dialog box informing you that you must reboot your computer.
  5. Click OK in the System Properties dialog box.
  6. Click Yes to restart your computer.

Configure the Front-end ISA Firewall’s Default Internal Network

When the front-end ISA firewall was installed, it took its definition from the routing table on the front-end ISA firewall device. The routing table entries indicated to the ISA firewall installer that the addresses 10.0.1.0-10.0.1.255 should be included in the definition of the default Internal Network. This is a correct configuration if the only network behind the front-end 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 control through the front-end ISA firewall.

The reason for the problem with the initial settings for the default Internal Network on the front-end ISA firewall is that there is a Route relationship between the DMZ network (which is the front-end ISA firewall’s default Internal Network) and the default Internal Network behind the back-end ISA firewall. Because there is a route relationship, connections from SecureNAT clients located behind the back-end ISA firewall will reach the front-end ISA firewall with their original client IP address included as the source address (this is not the case with proxied connections by Winsock [Firewall] and Web proxy clients). If we leave the front-end ISA firewall’s default Internal Network definition as it is now, then connections from SecureNAT client located behind the back-end ISA firewall will be detected as spoofed packets.

The reason for this is that 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 front-end ISA firewall, the root of the 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 default Internal Network’s definition is made through the interface that is the root of the front-end ISA firewall’s default Internal Network (which is the internal interface of the front-end ISA firewall), then the connection is dropped as a spoof attempt, since the ISA firewall assumes that it’s not possible for an interface to accept a connection from a host on a Network that isn’t the same as that for which the interface is root.

We can easily solve this problem by adding the IP addresses included in the back-end ISA firewall’s default Internal Network to the definition of the front-end ISA firewall’s default Internal Network definition.

Perform the following steps to add the IP addresses of the back-end ISA firewall’s default Internal Network to the definition of the front-end ISA firewall’s default Internal Network:

  1. In the ISA firewall console, expand the server name and then expand the Configuration node. Click on the Networks node.
  2. On the Networks node, click the Networks tab in the details pane, then double click the Internal Network.
  3. In the Internal Properties dialog box, click the Addresses tab.
  4. On the Addresses tab, click the Add button.
  5. In the IP Address Range Properties dialog box, enter the Starting address and the Ending address in the text boxes. In this example we’ll enter 10.0.0.0 and 10.0.0.255, respectively. Click OK.


Figure 2

  1. Click OK in the Internal Properties dialog box.


Figure 3

Configure a Routing Table Entry on the Front-end ISA Firewall

Like the situation with the DMZ Web server, you need to configure a routing table entry on the front-end ISA firewall that will enable it to know the route to the default Internal Network located behind the back-end ISA firewall. Perform the same procedure you did on the DMZ Web server to create the routing table entry providing the route to the default Internal Network behind the back-end ISA firewall.

Create an All Open Access Rule on the Front-end ISA Firewall

In the example discussed in this article, we will create an All Open access rule on the front-end ISA firewall allowing all traffic outbound from the default Internal Network to External. I’m using this only to keep the scenario simple so that we can focus on main thrust of this article, which is DMZ configuration. This is not what I would recommend you do in a production environment.

What would I do in a production environment? Some things I would consider include:

  • Allow outbound access through the front-end ISA firewall only for DMZ hosts that need to initiate new connections.
  • Not allow outbound access through the front-end ISA firewall for published servers on the DMZ and on the corporate network behind the back-end ISA firewall who do not need to make new outbound connections to the Internet
  • Allow outbound connections for all protocols from the primary IP address on the external interface of the back-end ISA firewall. This is the IP address that will be presented to the front-end ISA firewall for Web proxy and Firewall client located behind the back-end ISA firewall

These are just some very high level considerations, and outbound access requirements though the front-end ISA firewall will vary with the nature of communications allowed to and from the DMZ segment, as well as the internal networks located behind the back-end ISA firewall

Perform the following steps to create the All Open outbound access rule on the front-end ISA firewall:

  1. At the front-end ISA firewall, in the ISA firewall console expand the name of the server and then click the Firewall Policy node in the left pane of the console.
  2. Click the Create New Access Rule link on the Tasks tab in the Task Pane.
  3. In the Welcome to the New Access Rule dialog box, enter a name for the rule in the Access Rule name text box. In this example we’ll name the rule All Open Outbound. Click Next.
  4. On the Rule Action page, select the Allow option and click Next.
  5. On the Protocols page, select the All outbound traffic option from the This rule applies to list and click Next.
  6. On the Access Rule Sources page, click the Add button.
  7. In the Add Network Entities dialog box, click the Networks folder and double click the Internal entry. Click Close.
  8. Click Next on the Access Rule Sources page.
  9. On the Access Rule Destinations page, click the Add button.
  10. In the Add Network Entities dialog box, click the Networks folder. Double click the External Network. Click Close.
  11. Click Next on the Access Rule Destinations page.
  12. On the User Sets page, accept the default entry, All Users, and click Next.
  13. Click Finish on the Completing the New Access Rule Wizard page.
  14. Click Apply to save the changes and update the firewall policy.
  15. Click OK in the Apply New Configuration dialog box.

Have Questions about the article? 

Ask at: http://tinyurl.com/qxpsn

Create a Web Publishing Rule on the Front-end ISA Firewall

Now we’ll create a Web Publishing Rule to test the solution. The Web Publishing Rule will be a simple one and will not require authentication at the ISA firewall. The only authentication that will be required will be at the Web site itself. Again, in a production environment, I recommend that if you require authentication at the Web server in the DMZ, you should enhance security by employing pre-authentication at the ISA firewall. However, if the front-end ISA firewall is not a member of the same domain as the published Web server, or if the user accounts are not mirrored on the front-end ISA firewall, then the user will be challenged for authentication twice: once by the front-end ISA firewall and once at the Web site itself.

We will create a Web Publishing Rule that allows users who enter the URL http://dmzweb.msfirewall.org access to the Web server in the DMZ. If you want to replicate this configuration, you should make a HOSTS file entry on the front-end ISA firewall that maps the public name of the DMZ Web server to the IP address of the Web server in the DMZ. In addition, the public DNS must contain a Host (A) record for the server that maps to the IP address on the external interface of the front-end ISA firewall.

Perform the following steps to create the Web Publishing Rule:

  1. In the ISA firewall console, expand the server name and then click the Firewall Policy node.
  2. On the Firewall Policy node, click the Tasks tab on the Task Pane and then click the Publish a Web Server link.
  3. On the Welcome to the New Web Publishing Rule Wizard page, enter a name for the Web Publishing Rule in the Web Publishing Rule name text box. In this example, we’ll name the rule Publish DMZ Server. Click Next.
  4. On the Select Rule Action page, select the Allow option and click Next.
  5. On the Define Website to Publish page, enter the name of the DMZ Web server in the Computer name or IP address text box. Remember, the ISA firewall must be able to resolve this name to the actual IP address of the DMZ Web server on the DMZ Network. We will allow access to all folders on this site, so enter a /* in the Path text box. It’s usually a good idea to forward the original host header, since this enables many applications that perform server side scripting to work correctly. Click Next.


Figure 4

  1. On the Public Name Details page, select the This domain name (type below) option from the Accept requests for drop down list. In the Public name text box, enter the name that external users will use to access the site. In this example, external users will use the name dmzweb.msfirewall.org to access the site so we will enter that value. We want to allow access to all folders on the site, so we will leave the Path (optional) setting at the default (which is based on the path setting we specified on the previous page in the Wizard). Click Next.


Figure 5

  1. On the Select Web Listener page, click the New button.
  2. On the Welcome to the New Web Listener Wizard page, enter a name for the Web Listener. In this example we’ll name the listener HTTP Listener. Click Next.
  3. On the IP Addresses page, put a checkmark in the External checkbox and click Next.


Figure 6

  1. Accept the default settings on the Port Specification page and click Next.
  2. Click Finish on the Completing the New Web Listener Wizard page.
  3. Click Next on the Select Web Listener page.
  4. Accept the default setting on the User Sets page and click Next.
  5. Click Finish on the Completing the New Web Publishing Rule Wizard page.
  6. Click Apply to save the changes and update the firewall policy.
  7. Click OK in the Apply New Configuration dialog box.

Test the Solution

Let’s test the configuration. On a host on the External Network, make a connection to the published Web server. In this example, we’ll connect to http://dmzweb.msfirewall.org. You should see a single log on dialog box. Enter your credentials and you’ll see the home page for the site. Table 1 below shows a sample of log file entries on the front-end ISA firewall related to the connection attempt.


Table 1: Log file entries related to the external client connection to the published Web server in the DMZ (Click Table to Enlarge)

Table 2 shows a sample of log file entries related to the intradomain communications between the DMZ Web server and the domain controller on the corporate network.


Table 2: Intradomain communications between the DMZ Web server and the domain controller on the corporate network behind the back-end ISA firewall (Click Table to Enlarge)

Have Questions about the article? 

Ask at: http://tinyurl.com/qxpsn

Summary

In this article series we went over the concepts and procedures involved in placing a domain member computer on a DMZ segment in a back to back ISA firewall configuration. In this, part 3 of the series, we configured the front-end ISA firewall and established a connection from an external client. We then reviewed the log files on the front-end and back-end ISA firewall to see the details of the Web connection to the DMZ Web server and the intradomain communications between the DMZ Web server and the domain controller on the corporate network behind the back-end ISA firewall.

If you would like to read the other parts in this article series please go to:

About The Author

Tom Shinder is a Program Manager at Microsoft and has two decades of networking and security experience. He has written dozens of books, thousands of articles, and spoken at large industry conferences on the topics of IT infrastructure, Cloud computing, and cybersecurity. In his free time, Tom enjoys participating in equine prediction markets.

Read Next

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top