Creating a Parallel ISA Firewall Configuration in a Netscreen DMZ
Over the years there have been a number of questions about how to configure the ISA firewall in a “hardware” firewall’s “DMZ”. I have to admit that this question never made much sense to me, since I couldn’t figure out why the fledgling ISA firewall admin would want to create such a configuration. It seemed to be a simple affair to place the ISA firewall either in parallel or in a back to back configuration with the “hardware” firewall in front of the ISA firewall, allowing the ISA firewall to provide its superior level of protection nearest to the protected resources.
However, I recently participated in a thread where the fellow asking the question clearly stated his design goals and wanted to know how to best achieve them. You can read that thread over at http://forums.isaserver.org/Where_to_put_my_ISA_with_Netscreen%3f%3f%3f/m_2002002953/tm.htm
In that thread Ken said he had a Netscreen firewall in place and that he wanted to bring in an ISA firewall. He currently had a site to site VPN setup between Netscreen firewalls at the main and branch offices. His design goals for the ISA firewall included the following:
- Use the ISA firewall for Web filtering using SmartFilter
- Use the ISA firewall for Web caching for corporate network clients
- Publish Outlook Web Access (OWA) sites on the corporate network
- Publish RPC/HTTP or perhaps secure Exchange RPC
These are intelligent design goals because they all require features of the ISA firewall’s security model that aren’t available with the Netscreen. These include:
- The ISA firewall’s Web proxy filter, which allows him to use the SmartFilter add-on
- The ISA firewall’s Web proxy filter also enables the ISA firewall to act as a Web caching Web proxy device
- The ISA firewall’s Web proxy filter allows the ISA firewall to perform SSL to SSL bridging, which enables the ISA firewall to perform stateful application layer inspection on communications that would otherwise be hidden to the Netscreen firewall for secure OWA and RPC/HTTP publishing
- The ISA firewall is able to pre-authenticate users at the firewall before allowing any connections to the Web servers on the corporate network. This prevents attackers from leveraging anonymous connections directly to the published Web servers (including the Exchange Server’s Web server) to compromise the site
- The ISA firewall’s secure Exchange RPC filter, which enables users of all versions of the full Outlook client to access the Exchange Server from anywhere in the world without requiring a VPN connection or compromising the firewall’s security infrastructure by making “swiss cheese” out of the firewall policy
Ken had two requirements pertaining to his current infrastructure:
- Keep the current Netscreen device in place for the site to site VPN connections
- Keep the default gateway as the internal IP address of the Netscreen device
I thought about his requirements and drew some diagrams. The solution that best fits Ken’s requirements appears in figure 1. This design can be characterized in the following way:
- Both the Netscreen and the ISA firewalls are located behind an Internet router
- Both the Netscreen and the ISA firewalls have an external interface with IP addresses from Ken’s company’s public block of addresses
- The Netscreen has three NICs: one NIC is connected to the Internet (its external interface), one NIC is connected to the corporate network, and one NIC is connected to a perimeter network joining the Netscreen and the ISA firewall
- The perimeter network between the ISA firewall and Netscreen uses private addresses and the corporate network also uses private addresses
- The ISA firewall has two interfaces: one NIC connected to the DMZ joining the ISA firewall and Netscreen device, and one interface connected to the Internet
- A site to site VPN connections between the main and branch office Netscreens
Now let’s take a look at some of the details of the design and the rationale for putting things together this way.
The Netscreen is configured with a site to site VPN connection between the main and branch offices. I am assuming that the machines at the branch office access the Internet through their own Netscreen device and use the site to site VPN connection only to access server resources on the main office corporate network. However, if this is not correct, and Ken wants to force the client systems at the branch office to use the ISA firewall for Internet access, we can do that. As we’ll see later, we can use the Web proxy and Firewall client configurations to make this work.
Now you might wonder why we have the requirement to leave the Netscreen’s internal interface as the default gateway. The reason for this is that site to site VPN gateways act as routers and in order to route connections to the branch office, we need to set the Netscreen as the default gateway for on-subnet hosts, and the next hop gateway to the Internet for LAN routers.
The ISA firewall has an internal interface on the perimeter network (often referred to as the “hardware” firewall’s DMZ network) and an external interface on the company’s public block on the same network ID as the Netscreen’s external interface. The ISA firewall’s default Internal Network is defined as all addresses on the perimeter network, which in this scenario is just the IP addresses bound to the ISA firewall’s internal interface and the Netscreen’s DMZ interface, and all addresses on the corporate network.
Now we need to define the route relationships between the various networks. The Netscreen has the following route relationships:
- A route relationship between the main office corpnet and the branch office corpnet
- A NAT relationship between the main office corpnet and the Internet
- A route relationship between the corpnet and the perimeter network between the Netscreen and the ISA firewall
The ISA firewall has the following route relationships:
- A NAT relationship between the default Internal Network and the Internet. Notice that the ISA firewall has no knowledge of the perimeter network per se, and does not treat the perimeter network as an ISA firewall Network. Of course, if you wanted to place servers on that perimeter network, you could define a computer set and use that computer set for access controls, but that isn’t part of our scenario and design
- If the ISA firewall is later deployed as a remote access VPN server, then there would be a route relationship between the VPN Clients Network and the default Internal network
Have Questions about the article?
I mention the route relationship for the VPN Clients Network because Ken might want to later use the ISA firewall’s superior remote access VPN server capabilities instead of using the Netscreen as a remote access VPN server. Unlike the Netscreen, the ISA firewall enables you to implement finely tuned user/group-based access controls over what VPN users can access. In addition, the ISA firewall performs both stateful packet and application layer inspection on all remote access VPN client connections.
Now let’s take a look at the request/response paths for various connections to and from the corporate network and the Internet.
Figure 4 shows the request/response path for connections between the main and branch offices. This is a simple routed connection over the site to site VPN link created between the main and branch office Netscreen VPN gateways. This is Ken’s current configuration and we don’t need to change anything here.
Figure 5 shows the request/response paths for the internal network clients. Since the reason for bringing in the ISA firewall is to perform Web filtering and get enhanced monitoring of corporate user Internet activity, we want all user communications to be forced through the ISA firewall. We can accomplish this by configuring all client systems as Firewall and Web proxy clients.
The Web proxy and firewall client configurations enable the client systems to access the Internet independent of the client’s default gateway configuration. The reason for this is that the only route Web proxy and Firewall clients need to be aware of is the route to the internal interface of the ISA firewall.
Since all clients are configured to use the Netscreen as their default gateway, and the Netscreen knows the route to the IP address of the ISA firewall’s internal interface, then the connections from the Web proxy and Firewall clients are simply routed through the Netscreen to the internal interface of the ISA firewall.
The request/response path for Web and Server Publishing Rules is shown in figure 6. Here the connections from Internet hosts connect to the ISA address on the external interface of the ISA firewall. The ISA firewall then forwards the connections through the perimeter network between the ISA firewall and the Netscreen and then routed through the Netscreen to the corporate network. The responses are routed through the Netscreen to the ISA firewall and the ISA firewall returns the response to the Internet host.
There is an important configuration setting that we must enforce on all of our Web and Server Publishing Rules. For each publishing rule, you need to make sure the ISA firewall replaces the source IP address of the external client with its own address.
The reason for this is that the ISA firewall is not the default gateway for the corporate network servers. If we allowed the original external client IP address to remain as it is, the responses from the published servers would be sent to the internal interface of the Netscreen device, and then forwarded from the Netscreen’s external interface IP address to the external client. Since the external client made the request to the external IP address of the ISA firewall, and not the external IP address of the Netscreen firewall, the response will be dropped by the external client as an unsolicited inbound connection.
In contrast, when we replace the source IP address of the external client request with the IP address on the internal interface of the ISA firewall, the source IP address seen by the published server is the ISA firewall’s address and the published server returns the response to the ISA firewall. The ISA firewall then forwards the response to the external host on the Internet.
I should note that this isn’t the only possible design that would fulfill Ken’s requirements. For example, you could deploy the solution that appears in figure 7. In fact, this is my preferred configuration since it doesn’t make the Netscreen device the single point of failure for Internet access and provides an alternate gateway in the event that the Netscreen becomes unavailable. This configuration does not require corpnet hosts to change their default gateway settings and still allows us to leverage the Firewall client and Web proxy client configurations for outbound access control and use Web and Server Publishing Rules for inbound access control.
In this scenario, you have the option of preserving the source IP address of the external client in Web and Server Publishing Rules if you’re willing to enter a static route entry on the published servers to support connections from the branch office. The advantage of this approach is that you get the original client IP address in both the ISA firewall’s log files and in the log files of the published servers.
The reason why you might not want to use this configuration is that you have a “hardware” firewall that includes a DMZ interface that you’ve already paid for. Since you’ve paid a hefty premium to get an additional interface, you might want to take advantage of it and use the perimeter network that is part of the design that was the main topic of this article.
Before we finish, let’s revisit a possible scenario that Ken might want to implement. Since Ken wants tight control over outbound access at the main office, he might want to extend that control to client systems at the branch office. He can do that by deploying the Web proxy and Firewall client configuration to the branch office clients.
Figure 8 shows the request/response path for these connections. The Web proxy and Firewall clients at the branch office are configured with the IP address of the internal interface of the ISA firewall. The connections from the branch office Firewall and Web proxy clients are forwarded over the site to site VPN link and then to the ISA firewall’s internal interface of the perimeter network between the Netscreen’s DMZ interface and the ISA firewall’s internal interface. The ISA firewall then forwards the connections to the Internet and the responses are returned along the same path that the requests were made.
In order for this to work, there are some basic requirements and limitations:
- In all scenarios, the ISA firewall should be a member of the domain. This is an ISA firewall best practice for any scenario where outbound access control is a requirement, and for most inbound access (publishing) scenarios as well
- The client systems on the branch office network must be members of the same or a trusted Active Directory domain as the ISA firewall
- The IP addresses used at the branch office must be included in the definition of the ISA firewall’s default Internal Network
- ISA firewall SecureNAT clients are not supported because the ISA firewall is never set as a route of last resort in this design
- In all scenarios discussed in this article (with the exception of that depicted in figure 7), all Direct Access connections must be sent to the Netscreen. Any security applied to Direct Access connections are limited to the Netscreen’s security capabilities.
In this article I focused on a problem that Ken introduced on the ISAserver.org message boards. Ken had an existing site to site VPN connections between two Netscreen devices and wanted to bring in house an ISA firewall to enforce strong user/group based access control for outbound access, and also take advantage of the ISA firewall’s robust support for highly secure Web and Server Publishing Rules allowing inbound access to Microsoft Exchange Server resources. While there are a number of solutions to this problem, I concluded that the best one for Ken would be to take advantage of the DMZ interface on his Netscreen. This configuration supports all of his requirements, and leaves open the option to take advantage of the ISA firewall’s full feature set for both main office and branch office security.