Security

SolutionBase: Configuring remote access VPN connections in a back-end ISA firewall configuration

Using ISA Server on your network can become problematic if you're using remote access VPNs as well. In this article, Tom Shinder outlines some of the problems you can face in such a configuration and what to do about them.

Bringing a new firewall into your network is never a simple proposition. On one hand, you want to take advantage of the features and security advantages provided by the new firewall, but on the other hand you don't want to disrupt your current network infrastructure, as such disruptions have the potential for creating more downtime than you can tolerate.

Probably the easiest approach to bringing a new firewall into the mix is to use the Rip and Replace method, where you configure the new firewall with the same IP addressing information as the previous firewall and then pull out the old firewall and drop in the new one. While this might seem simple on paper, the realities are that organizations often have large "sunk costs" in their current firewall infrastructure and want that current infrastructure to earn out before completely replacing it.

Another important consideration is that the new firewall may employ a completely different management and policy model, which may or may not be consistent with what the organization previously had in place.

For these reasons and more, I often recommend that when you introduce a new ISA firewall into a company that you take advantage of the current infrastructure instead of using the Rip and Replace approach. While there are a number of possible designs you can use, the most secure option is to use a back to back firewall configuration.

In the back to back firewall configuration, the company keeps its current firewall on the Internet edge as a front-end firewall and places the ISA firewall behind it. This places the most secure firewall, the ISA firewall, closest to the assets the firewalls are designed to protect.

Introducing an ISA firewall to a pre-existing remote access VPN infrastructure

I encounter these infrastructure design and configuration issues often and one issue that frequently comes up is how to deal with remote access VPN client connections to the corporate network. Most companies with an existing firewall infrastructure already have their remote access VPN client connections setup to use the current firewall as a VPN server and may have already deployed proprietary, non-RFC compliant VPN client software that connects only to that vendor's firewall. These companies want to keep their current remote access VPN infrastructure in place but also want to enable the VPN clients access to resources on the corporate network located behind the ISA firewall.

Another very common scenario where there is a pre-existing remote access VPN server in place is when the company is using some type of "broadband" NAT device to connect to the Internet but want to bring in an ISA firewall as a back-end ISA firewall. The most common situations for this type of configuration is when the company must use PPPoE to connect to the DSL network, or when they must use DHCP for to obtain a public address for a cable network.

The latter scenario, where there is a NAT device in front of the ISA firewall is most commonly seen with SBS 2003 Service Pack 1 with the ISA firewall installed on it and the SBS box is configured as a multihomed server. While it has never made much sense to me, frequently users want to terminate their remote access VPN connections at the NAT device in front of the SBS box, but still want access to resources located on the SBS computers and to resources located on the corporate network behind the SBS server.

In both the SBS/front-end NAT device and corporate front-end network firewall infrastructure scenarios, the company wants to terminate the remote access VPN connection on a device in front of the ISA firewall and not at the ISA firewall and they want a method to allow the remote access VPN clients access to resources located behind the back-end ISA firewall. It is this scenario that I'll focus my attention on in this article series.

Author's Note

While the principles and procedures I discuss in this article series can be applied to SBS 2003 Service Pack 1 with ISA 2004 deployments, I will not go over the specific step by step procedures required to make the configuration work in that environment. I'll leave it up the SBS MVPs to provide that level of detail to their community.

In this article we'll focus on the following issues and procedures:

  • Terminating the VPN connection at the front-end firewall - Issues that must be addressed when terminating the remote access VPN client connections in front of the ISA firewall
  • Configuring the front-end VPN server IP addressing for VPN clients - VPN clients must be assigned IP addressing information that enable them to connect to the DMZ between the front-end firewall or NAT device and the ISA firewall, and enable connections to the corporate network located behind the ISA firewall.
  • Configuring the ISA firewall - The ISA firewall configuration will include configuring a new ISA firewall Network for the DMZ between the firewalls, configuring a Network Rule and Access Policy controlling traffic through the ISA firewall to and from remote access VPN clients.
  • Creating the FE DMZ network - We will create a new ISA firewall Network from the address range used by the network ID used on the network segment between the front-end firewall and the ISA firewall on the back-end.
  • Configuring the network rule between the default internal network and the FE DMZ network - After the new ISA firewall Network is created, we'll create a Route relationship between the DMZ and the default Internal Network located behind the ISA firewall.
  • Configuring ISA firewall policy for FE DMZ VPN clients - Firewall policy controlling what traffic can move through the ISA firewall to and from the remote access VPN clients must be configured. DNS rules may also be created to enable name resolution for the remote access VPN clients.
  • Configuring VPN client software - VPN client software must be configured for the remote access VPN connection. This includes VPN protocol and support for split tunneling, if required. There may be an option for the remote access VPN client to act as one or more ISA firewall clients types during the remote access VPN client connection.
  • Web proxy client support - The remote access VPN client might be able to support Web proxy client connections to the ISA firewall during the VPN session. We'll see what issues are involved here and an example configuration.
  • Firewall client support - Firewall client support is not available in this scenario. We'll examine the issues here and explain what you lose in terms of security when terminating the connection at the front-end firewall instead of at the ISA firewall.
  • SecureNAT client support - The remote access VPN clients are de facto SecureNAT clients of the ISA firewall. We'll discuss the implications and limitations of this situation.
  • Testing the connections - The proof of the pudding is in the eating, and in this section we'll examine what takes place during the remote access VPN client connections when they access the Internet and resources on the corporate network behind the ISA firewall (or even on the ISA firewall itself).

Terminating the VPN connection at the front-end firewall or NAT device

Before going into the configuration details involved with setting up a remote access VPN solution with the termination point in front of the ISA firewall, you should have some basic understanding of the network architecture, routing relationships, and response/response paths for various types of connections made through the remote access VPN connection.

Figure A shows the basic network architecture of a remote access VPN solution where the remote access VPN client terminates the VPN link at the firewall or NAT device located in front of the ISA firewall. In the figure there is green line representing the remote access VPN link to the firewall or NAT device's external interface.

The internal interface of the front-end firewall/NAT device is connected to a common hub or switch to which the external interface of the ISA firewall is connected. You can also use this network segment to connect Web, FTP and other anonymous access servers to which you want to allow anonymous access from Internet-based clients.

The external interface of the ISA firewall is connected to the common hub/switch to which the internal interface of the front-end firewall or NAT device is connected, as well as any servers that might be placed in the DMZ. Note that an independent hub/switch is not required. Many firewalls and NAT devices have multiple LAN ports. In that case, you can plug the external interface of the ISA firewall into one of the device's LAN ports and you can plug any anonymous access servers you want into the same device.

It's critical that you do not allow any direct connections from the protected network behind the ISA firewall and the DMZ network or the Internet. The ISA firewall must be inline in order to control all inbound and outbound traffic to and from the corporate network. I'll diagram what I call the Nightmare Scenario that violates this security requirement a little later in this article.

The reason why I make it a point to state that you should allow only anonymous access servers in the DMZ between the ISA firewall's external interface and the firewall/NAT device in front of the ISA firewall is that you are completely dependent on the security provided by the NAT device or simple stateful inspection firewall in front of the ISA firewall to protect the communications going into and out of the DMZ segment.

For this reason, you should not place critical corporate assets in this DMZ. An exception to this security guideline would be if you are using a front-end/back-end ISA firewall configuration, or if you were using a firewall that provides a high level of security similar to the ISA firewall, such as the Check Point firewall with application intelligence.

Figure A

Terminating the VPN connection at the NAT device or simple stateful packet inspection firewall

Understanding the routing relationships for communications to and from the remote access VPN client is a key component of making this solution work. Figure B diagrams the routing relationships between the various networks:

  • There is a ROUTE relationship between the default Internal Network behind the ISA firewall and the DMZ segment between the ISA firewall and the firewall/NAT device in front of the ISA firewall. This allows us to create both Publishing and Access Rules to control the traffic between the remote access VPN clients and the corporate network
  • There is a ROUTE relationship between the default Internal Network behind the ISA firewall and the Internet. A Network Rule that sets a route relationship between the default Internal Network and the default External Network is created automatically when you install the ISA firewall on a multihomed device and enforces this ROUTE relationship between Internal and the Internet
  • There is a ROUTE relationship between the remote access VPN client and the DMZ between the ISA firewall and the front-end firewall/NAT device. The ISA firewall is not aware of this and does not need to be aware of this, as it doesn't impact on the configuration of the ISA firewall
  • There is a ROUTE relationship between the default Internal Network and the remote access VPN client. The reason for this is that we must set a route relationship between the default Internal Network and the DMZ between the ISA firewall and the front-end firewall/NAT device. Since the remote access VPN client will be assigned an IP address on the same network ID used on the DMZ segment, the route relationship between the default Internal Network behind the ISA firewall and the remote access VPN clients is the same as the route relationship between the default Internal Network and the DMZ, which is ROUTE.

Figure B

Terminating the VPN Connection at the NAT device or simple stateful packet inspection firewall and the route relationships between the Networks

Now that you understand the key route relationships for all communications related to remote access VPN client connections, the next step to understanding how the solution works is to review the request/response paths for communications to and from the remote access VPN clients.

In Figure C, four request/response paths are described:

  1. This is the request/response path for connections between the remote access VPN clients and the default Internal Network behind the ISA firewall. There is a route relationship governing these connections, which allows you to use both Access Rules and Publishing Rules to control the level of access remote access VPN clients have when connecting to the corporate network behind the ISA firewall.
  2. This is the request/response path for connections between the remote access VPN clients and the DMZ between the ISA firewall and the front-end firewall/NAT device. Access control over VPN client connections to the DMZ is determined by the capabilities of the front-end firewall/NAT device. If you have a higher end device on the front-end, you may be able to exert packet filter based access control, or even user based control. If you have only a simple stateful packet inspection firewall or NAT device, you won't have much control, if any, over what the remote access VPN clients can access on the DMZ network.
  3. This is a request/response path for connections to Internet resources. This is one of two options, depending on the capabilities of your front-end firewall or NAT device. If your front-end firewall/NAT device does not support looping back to the Internet to allow the remote access VPN clients to connect to Internet resources, then you can configure the remote access VPN client software to allow split tunneling. While split tunneling is typically considered a security risk, this is your only option if your front-end firewall/NAT device does not support looping back through its external interface to allow remote access VPN clients access to the Internet.
  4. This is a request/response path for connections to Internet resources. This is the second option, where the front-end firewall or NAT device does allow the remote access VPN client to loop through the device to connect to Internet resources. This prevents the need to enable split tunneling on the remote access VPN client and also potentially provides you the option to enforce some form of corporate firewall policy on the remote access VPN client when it's connected to the VPN server. While this configuration has the advantage of preventing security issues related to split tunneling, it does suffer from the bandwidth toll taken by VPN clients connecting to the Internet through the corporate Internet connection.

Figure C

Terminating the VPN connection at the NAT device or simple stateful packet inspection firewall and request/response paths for corpnet and Internet connections

Figure D shows the request/response paths available when you configure the remote access VPN client to use the ISA firewall as its Web proxy device when connected to the remote access VPN server:

  1. This request/response path is used for all non-HTTP/HTTPS connections when the front-end firewall/NAT device does not support looping back through the device to connect to the Internet.
  2. This request/response path is used for all non-HTTP/HTTPS connections when the front-end firewall/NAT device support looping back through the device to access the Internet
  3. This request/response path is used for all HTTP/HTTPS/HTTP tunneled FTP requests when the remote access VPN client is configured to use the ISA firewall as its Web proxy server when connected to the VPN server. The ability to do this depends on the VPN client software you use and its integration with Windows. For example, if you use the native VPN client software that comes with Windows XP Service Pack 2, you can connect to the front-end firewall/NAT device using the PPTP, L2TP/IPSec and L2TP/IPSec NAT-T VPN protocols.

You can then configure the VPN client machine to use the ISA firewall as a Web proxy device when connected to the VPN server in front o the ISA firewall. This allows you to enforce ISA firewall policy and content filtering on the remote access VPN client when it's connected to the VPN server. This configuration also allows you to comprehensively log all sites and content these users access, and includes the user name in the log files, which can be used in reports of the user's Internet activity when connected to the VPN server. The Web proxy client configuration is automatically stopped when the client disconnects from the VPN server in front of the ISA firewall. Support for Web proxy client configuration varies the VPN client software you choose to use.

Figure D

Terminating the VPN Connection at the NAT device or simple stateful packet inspection firewall and request response paths for Internet connections including Web proxy client connections

Figure E depicts what I call the Nightmare Scenario and something I see mostly with SBS networks setup by someone unfamiliar with the ISA firewall security model and network security in general. I also see it attempted with users unfamiliar with TCP/IP networking.

In the Nightmare Scenario, there is a path that allows connections between the corporate network and the DMZ and Internet to bypass the ISA firewall. People most often try to accomplish this by putting a hub/switch between the ISA firewall's external interface and the firewall/NAT device and plugging the external interface of the ISA firewall and the internal interface of the front-end firewall/NAT device into the same hub/switch. In addition, they plug this hub/switch to another hub/switch located on the corporate network. This provides a bypass route away from the ISA firewall.

This is a Nightmare Scenario because:

  1. It provides a bypass route that enables malicious users to bypass the ISA firewall.
  2. It won't work. The internal and external interfaces of the ISA firewall must be on different network IDs. The external interface of the ISA firewall must be on the same network ID as the LAN interface of the front-end firewall/NAT device. Since the ISA firewall's external interface must be on a different network ID as the ISA firewall's internal interface, then the LAN interface on the front-end firewall/NAT device must be on a different network ID as the internal interface of the ISA firewall, which puts at least the on-subnet hosts on the default Internal Network on a different network ID as the LAN interface of the front-end firewall/NAT device.

Of course, you could get tricky and change the IP address and default gateway of a host on the default Internal Network so that the IP address is on the same network ID as LAN interface of the front-end firewall/NAT device, and then configure the client's default gateway as the IP address on the LAN interface of the front-end firewall/NAT device. This would allow a malicious user to completely bypass the ISA firewall to connect to the Internet, and a malicious external user to bypass the ISA firewall to access content on the corporate network.

You're playing a dangerous game when you allow users to bypass the ISA firewall at will. For this reason, the moniker of Nightmare Scenario is well-deserved.

Figure E

The Nightmare Scenario: Providing a path bypassing the ISA firewall

Do it right

In this article we discussed deployment options for introducing an ISA firewall into an established firewall and remote access VPN infrastructure. There are several infrastructure options available, with the most secure options enforcing all connections to and from the corporate network to pass through the ISA firewall. In order to gain a deeper understanding of how the solution works, we went over the route relationships between various networks that comprise the solution and the request/response paths to and from the remote access VPN clients. In the second part of this series, we'll go over the configuration details and discuss the rationale behind each configuration option.

Editor's Picks

Free Newsletters, In your Inbox