Configuring an Untrusted Wireless DMZ on the ISA Firewall – Part 2: Installing and Configuring the ISA Firewall

In part 1 of this two part series on how to create an untrusted wireless DMZ segment on the ISA firewall, we discussed the basic infrastructure elements required to make the solution work. We then went into detail on how to create a split DNS infrastructure to support the wireless DMZ segment. In this, part 2 of the two part series, we’ll finish up by going over the ISA firewall configuration details to complete the solution.

If you haven’t read part 1 of the series, check it out here http://isaserver.org/tutorials/2004wirelessdmzpart1.html

Now you’re ready to install the ISA firewall software. There are no special installation options you need to carry out at this point. During installation, you will be asked for the network interface representing the Default Internal Network. This interface will be used to define the Default Internal ISA firewall Network. You will not define the ISA firewall Network that defines the DMZ wireless network until after the ISA firewall software is completely installed.

I won’t go over the entire procedure for installing the ISA firewall software here. We have covered this procedure in painstaking detail in our book Configuring ISA Server 2004. Check out the book for details, tips and tricks for installing the ISA firewall software to meet your unique network requirements.

You need to create an ISA firewall Network for the wireless DMZ segment. The ISA firewall uses ISA firewall Networks to determine whether Networks are connected. In addition to using ISA firewall Network definitions to determine whether Networks are connected, the ISA firewall also uses ISA firewall Network definitions to determine the routing relationship between the source and destination Network, which the options being Route or NAT.

ISA firewall Networks are defined on a per-network interface basis. Each network interface bound to the ISA firewall is the “root” of an ISA firewall Network, and all addresses directly reachable through a particular interface are included in the definition of a particular ISA firewall Network. No IP address can be used on more than one ISA firewall Network, because no IP address can be directly reachable from more than a single network interface on the ISA firewall device.

The implication of this fact is that all interfaces installed on the ISA firewall must be located on different network IDs. The ISA firewall does not support (without issues, at least), more than one network interface per network ID. There may be some exceptions to this issue, but I will not discuss them here, because the go past the scope of our discussion and are more related to unusual VPN server configurations.

In the example discussed in this article, the DMZ network interface has the IP address 172.16.0.1/16. Since this network interface is on network ID 172.16.0.0/16, the definition of the wireless DMZ ISA firewall Network includes the IP addresses 172.16.0.0-172.16.255.255. Note that you don’t actually need to include all the addresses in the network ID; you only need to include those addresses actually in use. The latter option is preferred in larger environments, where its likely that you’re going to use subnets of default private address network IDs throughout your organization.

Perform the following steps to create the DMZ ISA firewall Network:

1. In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name and then expand the Configuration node. Click the Networks node.
2. On the Networks node, click the Networks tab in the details pane of the ISA firewall console. In the Tasks tab in the Task Pane, click the Create a New Network link.
3. On the Welcome to the New Network Wizard page, enter DMZ in the Network name text box. Click Next.
4. On the Network Type page, select the Perimeter Network option and click Next.
5. On the Network Addresses page, click the Add Adapter button.
6. In the Select Network Adapters dialog box, select the DMZ interface and then put a checkmark in the DMZ interface’s checkbox. The network information pulled from the Windows routing table appears in the Network Interfaces Information box. Click OK.

7. Click Next on the Network Addresses page.
8. Click Finish on the Completing the New Network Wizard page.
9. The new ISA firewall Network appears in the list of Networks on the Networks tab.

We are assuming that clients on the wireless DMZ network are never trusted. Either the users aren’t trusted, or the machines are not under our administrative control, so the machines are not trusted in the scenario we’re talking about in this article. Because the users and machines are never trusted on the wireless DMZ, there’s nothing more we need to do with the configuration of the new DMZ ISA firewall Network.

However, there may be circumstances where you will want to configure the Properties of the new ISA firewall Network to support Firewall clients and Web proxy clients. When you configure support for Web proxy and Firewall clients, you can create rules that require the users to authenticate before accessing any content through the ISA firewall.

I won’t go into the details of configuring the Properties of the new ISA firewall Network representing our wireless DMZ in this article because of the assumptions we’re making for hosts that will exist on this network. In a future article, I’ll go over the details of ISA firewall Network Properties configuration to support Web proxy and Firewall clients in a scenario where the new ISA firewall Network represents an addition internal ISA firewall Network.

The SecureNAT clients on the DMZ segment need to resolve Internet host names using the DNS server on the ISA firewall. This requires an Access Rule allowing hosts on the DMZ segment access to the DNS server on the ISA firewall. In addition, hosts on the DMZ Network may want to access selected resources on the Default Internal Network that you publish to clients on the DMZ Network.

In the example discussed in this article, we will create a Secure Exchange RPC Server Publishing Rule. In order for the hosts on the DMZ Network to benefit from this rule, they must be able to resolve the name of the Exchange Server to the IP address bound to the DMZ interface of the ISA firewall. This is a part of a split DNS infrastructure. Hosts on the Default Internal Network use the Internal DNS server which resolves the name of the Exchange Server to the Exchange Server’s actual internal IP address and hosts on the DMZ Network resolve the name of the Exchange Server to the IP address used in the Server Publishing Rule that publishes the Exchange Server to the hosts on the DMZ Network.

Note that a spilt DNS infrastructure can have multiple “splits”. If we also wanted to publish the Exchange Server to hosts on the Internet (or any other external Network that would access the Exchange Server through the ISA firewall’s external interface), we would need to create another DNS zone accessible to those hosts which would resolve the name of the Exchange Server to the IP address bound to the external interface of the ISA firewall.

This rule is optional. However, if you have users who need to access the Exchange Server on the Default Internal Network, you can create a Secure Exchange RPC Server Publishing Rule to allow full Outlook MAPI client access to the Exchange Server without requiring a VPN. This rule is very useful if you find that are times when you want to bring a wireless device onto your network and do not want to access any resources on the production network other than Exchange/Outlook. In this scenario, you can connect to the Exchange Server through the Secure Exchange RPC Server Publishing Rule and not even use a VPN connection.

An alternative to this configuration would be to bring a second WAP into the network, and connect that WAP to the production Network. This WAP would require WPA authentication and only trusted computers and users would have the required certificates installed to connect to the production network’s WAP.

This rule is optional. If you are hosting your own SMTP services on the Exchange Server, you can create an SMTP Server Publishing Rule allowing inbound SMTP access to the Exchange Server’s SMTP service. If you are not hosting your own SMTP server, this rule is not required.

You want to provide limited and secure connections from the DMZ segment. For this reason, we typically allow only HTTP connections outbound. The leaves the option open to configure the HTTP Security Filter to block dangerous applications and block dangerous SSL tunneled applications (such as SSL “VPN” connections).

This decision is a somewhat restrictive one, but I consider it the best course of action because we make the assumption that hosts on the DMZ segment are neither trusted computers or users. Because of that, we need the ISA firewall to perform both stateful packet inspection and stateful application layer inspection on communications moving through the ISA firewall from the DMZ segment to the Internet. If we allow encrypted communications, such as SSL and VPN connections from untrusted users and computers to the Internet, those communications will be hidden from the ISA firewall and stateful application layer inspection is impossible.

This creates a scenario where the ISA firewall can provide no more protection than a conventional stateful packet inspection firewall; a situation we want to avoid if at all possible.

We’ll create an “All Open” rule allowing all protocols from the Default Internal Network to the Internet. OK, if this isn’t recommended, why am I creating such a rule for this article? Because each network will have its own security policy, which can be potentially complex. I’m taking the easy way out here by creating an All Open rule.

In a production network, the ISA firewall should be a member of the domain, and you should use strong user/group based access controls to provide granular outbound and inbound access through the ISA firewall. All client operating systems on the production network would be configured as Web proxy and Firewall clients, and all servers requiring Internet access (including published servers) would be configured as SecureNAT clients.

Its important to point out the importance of strong user/group based access control, because this is one of the cornerstones of the ISA firewall’s superior security model over that you would obtain from a traditional stateful packet inspection-only firewall. In addition to granular user/group based access control, this configuration also places user names and Web site names into the log files, which makes it easy to correlate user names with Internet protocol and site usage. You can create per-user reports and use this information to remediate user behaviors.

In addition to the above access rules, you may want to provide a method to allow hosts on the wireless DMZ more comprehensive access to resources on the corporate network. There are several ways you can do this. One method is creating a set of Web and Server Publishing Rules for all the resources you can imagine hosts on the wireless DMZ would ever require. Another approach is to use a Route relationship between the wireless DMZ and the Default Internal Network and then create Access Rules allowing connections from the wireless DMZ to the default Internal Network. The last option, and my preferred option, is to enable the ISA firewall’s VPN component and then configure the VPN server to listen for incoming connections on the DMZ interface.

To accomplish the last option, you will need to do the following:

You might want to allow clients on the wireless DMZ more comprehensive access to Internal Network resources. You can use a VPN connection from the wireless DMZ to make this happen in a secure fashion. Depending on your network security requirements, you can configure the ISA firewall to act like a traditional VPN server that allows the VPN clients access to all protocols and resources on the corporate network, or you can lock down your VPN clients so that they access only the protocols and resources they require on a per-user/per-group basis. The latter configuration is more secure and is my recommended setup in a production environment.

While granular user/group based access control on VPN clients is the most secure configuration, in the example provided in this article we will provide all users logged onto the VPN server access to all resources using all protocols to the Default Internal Network and the Internet. This isn’t meant to be a recommendation or an example of ISA firewall best practices, but rather to save some time in demonstrating the procedures which are the primary focus of this article.

For comprehensive guidance on creating and configuring firewall policy and setting up high security user/group based access controls on a per resource/per protocol basis for VPN connections, check out the discussions related to these topics in our book Configuring ISA Server 2004.

The tables below show the basic construction of each rule that we will include in the ISA firewall’s firewall policy.

*Note that we won’t be able to create this rule until we enable the ISA firewall’s VPN server component.

The ISA firewall’s firewall policy will end up looking like that in the figure below.

Let’s start with the All Open rule allowing all traffic from the Default Internal Network to the Internet:

1. In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name and then click on the Firewall Policy node. Click the Tasks tab in the Task Pane and click the Create a New Access Rule link.
2. On the Welcome to the New Access Rule Wizard page, enter a name for the rule in the Access Rule name text box. In this example we’ll name the rule All Open Internal to Internet and click Next.
3. On the Rule Action page, select the Allow option and click Next.
4. Accept the default setting on the Protocols page, All outbound traffic, and click Next.
5. On the Access Rule Sources page, click the Add button.
6. On the Add Network Entities page, click the Networks folder and then double click the Internal entry. Click Close.
7. Click Next on the Access Rule Sources page.
8. On the Access Rule Destinations page, click Add.
9. In the Add Network Entities dialog box, click the Networks folder and double click the External entry. Click Close.
10. Click Next on the Access Rule Destinations page.
11. On the Users Sets page, select the default setting, All Users, and click Next.
12. Click Finish on the Completing the New Access Rule page.

Perform the following steps to create the rule that enables HTTP access from the DMZ Network to the Internet:

1. On the Firewall Policy node. Click the Tasks tab in the Task Pane and click the Create a New Access Rule link.
2. On the Welcome to the New Access Rule Wizard page, enter a name for the rule in the Access Rule name text box. In this example we’ll name the rule HTTP DMZ to Internet and click Next.
3. On the Rule Action page, select the Allow option and click Next.
4. On the Protocols page, select the Selected protocols option and click Add.
5. In the Add Protocols dialog box, click the Common Protocols folder and double click the HTTP protocol. Click Close.

6. Click Next on the Protocols page.
7. On the Access Rule Sources page, click the Add button.
8. On the Add Network Entities page, click the Networks folder and then double click the DMZ entry. Click Close.
9. Click Next on the Access Rule Sources page.
10. On the Access Rule Destinations page, click Add.
11. In the Add Network Entities dialog box, click the Networks folder and double click the External entry. Click Close.
12. Click Next on the Access Rule Destinations page.
13. On the Users Sets page, select the default setting, All Users, and click Next.
14. Click Finish on the Completing the New Access Rule page.

Perform the following steps to create the Access Rule allowing DNS protocol access to the DNS server on the ISA firewall:

1. On the Firewall Policy node. Click the Tasks tab in the Task Pane and click the Create a New Access Rule link.
2. On the Welcome to the New Access Rule Wizard page, enter a name for the rule in the Access Rule name text box. In this example we’ll name the rule DNS to ISA Firewall and click Next.
3. On the Rule Action page, select the Allow option and click Next.
4. On the Protocols page, select the Selected protocols option and click Add.
5. In the Add Protocols dialog box, click the Common Protocols folder and double click the DNS protocol. Click Close.

6. Click Next on the Protocols page.
7. On the Access Rule Sources page, click the Add button.
8. On the Add Network Entities page, click the Networks folder and then double click the DMZ entry. Click Close.
9. Click Next on the Access Rule Sources page.
10. On the Access Rule Destinations page, click Add.
11. In the Add Network Entities dialog box, click the Networks folder and double click the Local Host entry. Click Close.
12. Click Next on the Access Rule Destinations page.
13. On the Users Sets page, select the default setting, All Users, and click Next.
14. Click Finish on the Completing the New Access Rule page.

The last rule is for the Secure Exchange RPC Server Publishing Rule:

1. In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name and then click on the Firewall Policy node. Click the Tasks tab in the Task Pane and click the Create a New Server Publishing Rule link.
2. On the Welcome to the New Server Publishing Rule Wizard page, enter a name for the Server Publishing Rule in the Server Publishing Rule name text box. In this example we’ll name the rule Secure Exchange RPC. Click Next.
3. On the Select Server page, enter the IP address of the Exchange Server you want to publish in the Server IP address text box. Click Next.
4. On the Select Protocol page, choose the Exchange RPC Server protocol from the Selected protocol list. Click Next.

5. On the IP Addresses page, put a checkmark in the DMZ checkbox. Note that if you bind other IP addresses to the DMZ interface, this setting will allow a secure Exchange RPC connection to any IP address on that interface. You can narrow the IP address used for the rule by using the Address button. In this example there is only one IP address bound to that interface, so we don’t need to make any changes. Click Next.

6. Click Finish on the Completing the New Server Publishing Rule Wizard page.

Click the Apply button to save the changes and update firewall policy.

I often configure the DMZ interface on the ISA firewall to accept incoming VPN client connections so that a trusted user, with a trusted computer, on the wireless DMZ segment can obtain access to resources not published via publishing rules. VPN connections are used very often, but it does provide you a bit more flexibility.

In the past I had been a proponent of the PPTP VPN protocol because it provides a reasonable level of security when using complex passwords, and because its very easy to setup and configure. However, in the past year I’ve changed my attitude toward PPTP because of new Rainbow Crack and Rainbow table technologies. These technologies leverage the fact that the password hash is sent over an unencrypted channel between the VPN client and server. They are able to capture the hash and determine the password. They don’t need to do anything special to capture the user name, because this is exposed in clear text in the unencrypted channel.

Given this unfortunate situation, I now always recommend that you use L2TP/IPSec (not IPSec tunnel mode) for your VPN connections. Username and password are sent from the VPN client to the VPN server only after the secure tunnel is established.

When using L2TP/IPSec, you can use either pre-shared key or machine certificates for the machine authentication and IPSec encryption requirement. In a high security and well-managed environment, you will always use machine certificates. However, if you need to get things up and running quickly before your PKI is deployed, you can use pre-shared key. In the example covered in this article we will use pre-shared keys.

Perform the following steps to enable the ISA firewall’s VPN server component:

1. In the ISA firewall console, expand the server name and then click the Virtual Private Networks (VPN) node.
2. Click the Tasks tab in the Task Pane and click the Enable VPN Client Access link.
3. Click the Configure VPN Client Access link in the Task Pane.
4. On the General tab of the VPN Clients Properties dialog box, you’ll see the default number of VPN connections is set to 5. If you need more connections, change that number here.
5. On the Protocols tab, remove the checkmark from the Enable PPTP checkbox. Put a checkmark in the Enable L2TP/IPSec checkbox.
6. Click Apply and then click OK.
7. Click the Select Access Networks link in the Task Pane.
8. In the Virtual Private Networks (VPN) Properties dialog box, click the Access Networks tab. On the Access Networks tab, remove the checkmark from the External checkbox and place a checkmark in the DMZ checkbox. If you want to allow VPN connections from the Internet, then you can leave the checkmark in the External checkbox.

9. Click the Address Assignment tab. Notice that the default setting is for the ISA firewall to use DHCP to obtain addresses for VPN clients. I recommend that you use this option. However, it does require that the ISA firewall have access to a DHCP server on the Internal Network. If you do not use a DHCP server, then you will need to select the Static address pool option. If you use this option, you must use addresses that do not overlap with any other network addresses. For example, if you are using network ID 192.168.1.0/24 for the Internal Network, then you can’t use addresses in that network ID unless you remove the addresses you place in the static address pool list from the definition of the Internal Network. In contrast, when you use DHCP, you can use on-subnet addresses for your VPN clients. In the example discussed in this article, we have a DHCP server on the Default Internal Network that the ISA firewall can reach, so we will use the default option.

10. Click the Authentication tab. The default user authentication protocol is Microsoft encrypted authentication version 2 (MS-CHAPv2). You can leave this setting as it is unless you want to enable alternate authentication protocols. In order to force only trusted users and computers to use the VPN server, you can use EAP authentication and user certificate authentication. In the example discussed in this article, we’ll use the default setting. Put a checkmark in the Allow custom IPSec policy for L2TP connection checkbox. Enter the pre-shared key in the Pre-shared key checkbox. This is the same pre-shared key that you will enter on the VPN client.

11. Click Apply and then click OK in the ISA Server 2004 dialog box warning you that the RRAS service may restart. Click OK.
12. Click Apply in to save the changes to firewall policy.

The last step is to create the Access Rule allowing members of the VPN Clients Network access to the Internal Network and the Internet:

1. In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name and then click on the Firewall Policy node. Click the Tasks tab in the Task Pane and click the Create a New Access Rule link.
2. On the Welcome to the New Access Rule Wizard page, enter a name for the rule in the Access Rule name text box. In this example we’ll name the rule All Open VPN to Internet and Internal and click Next.
3. On the Rule Action page, select the Allow option and click Next.
4. Accept the default setting on the Protocols page, All outbound traffic, and click Next.
5. On the Access Rule Sources page, click the Add button.
6. On the Add Network Entities page, click the Networks folder and then double click the VPN Clients entry. Click Close.
7. Click Next on the Access Rule Sources page.
8. On the Access Rule Destinations page, click Add.
9. In the Add Network Entities dialog box, click the Networks folder and double click the External and Internal entries. Click Close.
10. Click Next on the Access Rule Destinations page.
11. On the Users Sets page, select the default setting, All Users, and click Next.
12. Click Finish on the Completing the New Access Rule page.

In this two part series we discussed the concepts and procedures behind creating an internal DMZ segment that hosts untrusted users and computers on a wireless DMZ segment. Procedures included setting up the DMZ before installing the ISA firewall, configuring the ISA firewall’s interfaces, creating a new ISA firewall Network, connecting the DMZ ISA firewall Network to other networks, creating access rules, and setting up the ISA firewall’s VPN server component.

In later articles we’ll build on concepts and procedures in this article to create additional internal network segments that are managed by access to other segments is controlled by the ISA firewall.