Playing Well with Others: Configuring the ISA Firewall on a PIX DMZ for Secure Remote Access to OWA and other Exchange Services

Playing Well with Others:
Configuring the ISA Firewall
on a PIX DMZ for Secure Remote Access to OWA and other Exchange Services



By Thomas W Shinder MD, MVP

In the last six months I’ve been pleasantly surprised by the number of companies who have come to the realization that protection provided by basic stateful packet inspection-only firewalls just isn’t enough to protect networks from today’s blended network and application layer attacks.

While the issue of stateful application layer inspection has been bubbling under the radar among network security professionals for years, its only been in the last 12-18 months that I’ve seen traditional network managers seriously question the efficacy of their current stateful packet inspection infrastructure and seek enhanced solutions, like the ISA firewall (which provide both stateful packet and application layer inspection.)

Questions I deal with now center around whether the ISA firewall should replace the current PIX infrastructure, or whether they should leave the PIX in place and integrate the ISA firewall’s stateful packet and application layer inspection firewall features to enhance the level of security provided by the PIX.

There are advantages and disadvantages of either decision. The advantages of keeping the PIX in place are:

The disadvantages of keeping the PIX in place include:

Overall, my typical preference is to leave the PIX in place. It usually won’t hurt anything, the company has already paid for it, and it mollifies IT managers who haven’t “got it” yet.

There are three setups I typically consider in this hybrid PIX and ISA firewall environment. These are:

In the back to back firewall setup, the PIX is placed in front of the ISA firewall and has at least one interface on the Internet and one on a network segment it shares with the external interface of the ISA firewall. This configuration makes the PIX the first device to see inbound traffic and the last device to see outbound traffic.

The major advantage of this configuration is that the PIX can handle all the inbound “garbage” traffic, which is any inbound traffic that you don’t want in. Such traffic includes all primary inbound traffic for resources that you’re not hosting for Internet users.

This configuration is easy to set up. The WAN interface of the PIX is configured with the appropriate public address and gateway router, and its LAN interface is configured on the same network ID as the external interface of the ISA firewall. The external interface of the ISA firewall is configured with an address on the same network ID as the LAN interface of the PIX, and the ISA firewall’s external interface is configured to use the LAN interface of the PIX as its default gateway.

The back to back firewall configuration supports almost all inbound and outbound connections to and from the corporate network. The only problematic configuration is for inbound and outbound secure Exchange RPC communications, because the PIX doesn’t have the appliance layer intelligence to perform the circuit filtering and protocol compliance required for secure Exchange RPC. The only way you could get it to work would be to open all high ports inbound and outbound through the PIX, which almost completely defeats the point of having the PIX as a front end device in the first place.

Firewall policy on the PIX is straightforward: allow everything outbound from the IP addresses bound to the external interface of the ISA firewall and allow inbound only the protocols that are being published by the ISA firewall.

For example, if you were publishing an OWA site behind the ISA firewall, you would configure the PIX for forward all TCP 443 connections it receives to the IP address on the external interface of the ISA firewall used in the Web listener.

Keep in mind that you can use either private or public addresses on the DMZ between the PIX and the ISA firewall. I prefer to use public addresses because of superior protocol support, but if you don’t have this option, private addresses work almost as well. However, be aware that some protocols and NAT editor combinations don’t always get along with each other in a “double NAT” configuration.

In the parallel firewall configuration, both the PIX and the ISA firewall have public and private interfaces. The public interfaces are configured with public block addresses and the private interfaces are configured with valid addresses on the corporate network. Typically, the public interfaces are on the same network ID and the private interfaces are also on the same network ID, although this certainly isn’t required depending on your own networks requirements.

The advantage of this configuration is that you benefit from the full stateful packet and application layer inspection for both inbound and outbound connections through the ISA firewall, and full inbound and outbound stateful packet inspection on the PIX.

You can deploy the full range of ISA firewall features including VPN, Web proxy and caching, Firewall client, inbound and outbound Secure Exchange RPC, and all of the other enhanced Exchange Server publishing features included with the ISA firewall. In addition, if you have a SIP-based VoIP gateway on the corporate network, you can configure that to use the PIX as its Internet gateway.

The PIX and ISA firewall can back each other up in the event that one of them becomes unavailable. You can use a hardware device between the corporate network hosts and the LAN interfaces of the firewalls, or use something as simple as the Internet Router Discovery Protocol to provide fail over protection (although there are some security issues with using IRDP).

I consider this the best configuration because it provides high availability, excellent protocol support, excellent security, and a relatively simple setup and configuration. All hosts on the corporate network use the ISA firewall as their inbound and outbound access point, except for those servers requiring SIP support. The PIX can act as a hot standby for the ISA firewall, or you can use it for devices requiring outbound access to the Internet, but do not require authentication for the outbound connections.

The ISA firewall in a PIX DMZ configuration enables you to provide comfort to old-school admins who still can’t sleep at night with an ISA firewall on the edge of the corporate network. This configuration reduces the push-back you might receive from the dyed-in-the-wool PIX guys, while still enabling you to get all the stateful packet and application layer protection and access control provided by the ISA firewall.

This setup uses the PIX as the edge firewall for the network. The PIX has three interfaces (DMZ license): A public interface, a private corporate network interface and a DMZ interface that it shares with the external interface of the ISA firewall. The ISA firewall’s external interface is on the same network ID as the DMZ interface of the PIX, and the ISA firewall’s internal interface is on the corporate network, on the same network ID as the private corporate network interface of the PIX.

The utility of this configuration is that by does an end-run around those concerned about putting a so-called “software firewall” on the edge of the network. Its critical to realize that not even the ISA Server 2000 firewall, which wasn’t nearly as secure and hardened against attack at the ISA Server 2004 firewall, was never reported to have been compromised from the external interface.

Now with the new ISA firewall, all interfaces are equally hardened, and the IP filter components lie much lower in the network stack, so that if the ISA firewall protection should ever fail, the entire stack would fail and no traffic will move to or through the firewall.

This configuration enables the PIX to be the only edge device and make the ISA firewall an essentially back-end firewall for inbound and outbound access to the Internet. The only difference between this and the front-end/back-end configuration we discussed earlier is that both the ISA firewall and the PIX have interfaces on the corporate network.

While this is obviously less secure (since only the PIX lies between the Internet and the corporate network), it effectively quiets traditionalists long enough so that the ISA firewall can prove itself.

You can use either public or private addresses in the DMZ network between the ISA firewall’s external interface and the DMZ interface on the PIX. The ideal situation is to use public addresses, as this obviates any NAT issues related to double NATing, as mentioned earlier in the back to back firewall configuration.

Firewall rules on the PIX should be configured to allow all inbound and outbound connections to and from the ISA firewall’s external addresses. The PIX can perform stateful layer 3 and 4 inspection and prevent network level exploits even when all connections are allowed to and from the ISA firewall’s external interface. The PIX should also be configured to allow no inbound traffic from the Internet to the corporate network, and allow outbound traffic only from specialized servers on the corporate network that provide services not fully supported by the ISA firewall (such as VoIP gateways).

All Windows client operating systems on the corporate network can be configured as Firewall and Web proxy clients of the ISA firewall. Non-Windows clients and servers can be configured as SecureNAT clients of the ISA firewall. As in the other scenarios, the PIX can be used as the Internet gateway address for VoIP gateways located on the corporate network.

This design allows you to take full advantage of the ISA firewall’s strong user/group based access control, logging and reporting, and also allows you to leverage its superior security support for remote access to Exchange Servers and services on the corporate network.

The figure below shows the inbound and outbound path for highly secure remote access to an Exchange OWA server using the ISA firewall in a PIX DMZ configuration.

The remote client on the Internet connects to the ISA firewall through the PIX. The address used by the remote client depends on whether you use public or private addresses on the DMZ between the PIX and ISA firewall. If private addresses are used on the DMZ, then the remote OWA client connects to the IP address on the external interface of the PIX and the PIX reverse NATs the connection to the external interface of the ISA firewall. If public addresses are used on the DMZ between the PIX and the ISA firewall, then the remote host can connect directly to the public address on the external interface of the ISA firewall.

Notice in the figure that the request and response paths are the same. Once the ISA firewall receives the connection request, it performs stateful packet and application layer inspection and if the connection attempt does not present a recognized or potential risk, it is forwarded to the OWA site on the corporate network. When the OWA site responds, it must send it response back through the ISA firewall and then the ISA firewall passes outbound to the remote client through the PIX.

For OWA publishing, the default setting on the ISA firewall is to replace the original client IP address with the IP address of the ISA firewall’s local interface (interface closest to the published OWA site). This allows you to configure the OWA site with a gateway address that doesn’t route outbound connections to the Internet through the ISA firewall, since the OWA site just needs to know the route to the IP address on the local interface of the ISA firewall. You even have the option to configure no default gateway address on the OWA site, as long as the OWA server does not need to initiate a non-proxied outbound connection to a Internet host.

However, you also have the option in the OWA Web Publishing Rule to retain the original IP address of the remote client. In this case, the OWA server must be configured as a SecureNAT client of the ISA firewall, since it needs to respond to an IP address that is not a local address.

This is true regardless of whether you use public or private addresses on the DMZ segment between the PIX and the ISA firewall. If you use public addresses, the OWA site will respond to the client’s actual address (or gateway address if the OWA client is behind a proxy or NAT device). If you use private addresses, then the OWA server will need to respond to the private address on the DMZ interface of the PIX (depending on how the PIX is configured to do half or full NAT).

In this article we went over the options available for integrating the ISA firewall in a established PIX (or other “hardware” firewall) environment. The best options include the back to back firewall configuration, the parallel firewall configuration, and the ISA firewall in a PIX DMZ configuration. The ISA firewall in a PIX DMZ configuration has several advantages over the other options, the most significant being that you can overcome some the anxieties traditional firewall and network managers have over placing a stateful packet and application layer inspection firewall on the edge of the corporate network. The primary downside of this configuration is that the PIX has an interface on the corporate network that isn’t protected by the ISA firewall.

I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, ask at http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=26;t=000353 I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom

If you would like us to email you when Tom Shinder releases another article on ISAserver.org, subscribe to our ‘Real-Time Article Update’ by clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy