10.8 Integrating the VPN and Firewall

A VPN can either be an asset to your company's security policy or a big gaping vulnerability, depending on its relationship with your organization's firewall. All that a VPN does is protect traffic that is in transit. It does nothing to protect the hosts that generate the traffic or to verify that the information that is being encrypted is actually good for your network. As far as a firewall is concerned, a firewall can only make forward or drop decisions on traffic that it can read. If all data is encrypted in an ESP session, then the firewall will have no way of making a decision on the contents of the encrypted data. When this is taken into consideration, it becomes much easier to determine the relationship between the firewall and the VPN.

As a general rule, you will want to consider all VPN traffic to be untrusted. Remember that just because it has been encrypted does not mean that the traffic is safe. Therefore, you will want all possible VPN traffic to be decrypted by the firewall and examined before being allowed into your network. This, of course, is not always possible. Consider the case of an HTTPS server that provides secure client connections to Web pages that it serves. Because the SSL connection that provides this encryption is established between the two hosts, it will be impossible for the firewall to examine this data without affecting the SSL session between the client and the server. Exceptions such as this can be remedied by placing such devices on DMZs created specifically for the services. In this way, even if the server is compromised by an encrypted session, the amount of damage or access to the remainder of the network can be minimized.

Exhibit 21 displays several network configurations that can be used in a gateway situation to enable VPN traffic and the firewall to interoperate with maximum protection for your network.

Exhibit 21: Possible Firewall/VPN Gateway Configuration

click to expand

We see that in each of the topologies in Exhibit 21, the VPN traffic is decrypted and examined by the firewall before being allowed into the internal network. If your security policy mandates that VPN traffic be allowed through the firewall, then it is advisable to have a separate DMZ for the VPN gateway. The key is that there is something checking the traffic as it enters your LAN. In some cases, this may even require host-based firewall systems, especially in the case of remote clients.

The interaction between a VPN and a firewall can be between two specialized devices: one acting as a VPN gateway and the other acting as a firewall, or between a single VPN/firewall appliance. When considering the relative security and performance of these two models, be sure to consider what would happen to your network security if your VPN device were compromised in some manner. The best security model, as cannot be mentioned enough, is defense in depth. Realistically, nobody short of a government or the ISP itself is going to spend a lot of time trying to capture your data as it crosses the Internet. Even fewer people are going to spend the time and effort to decrypt data that is captured. The far more likely and easier target is going to be the VPN gateway itself. Although we hope this is not the case, any VPN gateway (and firewall, for that matter) that we build or purchase has to be assumed to have a security flaw that allows an attacker access. Historical data has shown us time and time again that "secure" solutions have some sort of vulnerability that is just waiting to be discovered.

By placing the VPN and firewall functions into a single hardware appliance, we are making a large gamble that when vulnerability is found with our product, we will find out about it and have a fix available before anyone can damage the network. An attack against the device could render all of your perimeter network security worthless. With different devices housing your VPN and firewall functions, there is still the risk of compromise, but we have split our eggs into different baskets. Hopefully, one of those baskets will hold together long enough for us to fix the other.

There are also reliability issues associated with creating a single VPN/firewall appliance. A failure in that device will shut off Internet access until the device can be repaired. How long that timeframe is depends on the vendor of the product and the support agreement that you have signed. Unless a spare, identically configured box was already available, you can count on at least four hours of downtime in such an event. When separating the devices, a firewall failure may still be a show-stopper, but a VPN failure would still allow some useful work to occur.

Finally, there are performance issues to consider. A VPN/firewall appliance has that much more work to do than a stand-alone device. I agree wholeheartedly that vendors can produce combination devices with enough horsepower to serve both functions; the question is whether it would be a better investment to purchase those functions separately. When considering the overall cost of stand-alone or separate solutions, remember to include redundancy requirements and growth into any equation.

That said, it is difficult to resist the deployment of a single VPN/firewall appliance. Because the functions are tightly integrated, the issues surrounding filtering encrypted traffic and NAT are neatly taken care of. In fact, most integration problems between VPNs and firewalls are neatly taken care of. It is also alluring to be able to walk into a remote site and simply insert a preconfigured VPN/firewall box in-line with the egress access link and walk out. Installation of such devices can truly be a breeze when configuring many remote offices and can often be handled by nontechnical staff. Once again, there is no right solution to offer. The right solution is the one that most closely reflects the needs of your security policy and an intelligent budget that takes all circumstances into account.

The performance of a VPN device is often a point of discussion. Two questions that I am frequently asked inlcude, "How can I make sure that I get the best performing VPN?" or "How can I compare VPN gateways?" Comparisons based on vendor information are always tricky. Make sure you read the fine print. When citing the packet transfer rate, make sure that you know the size of the packets they are quoting and the type of encryption being used when making the comparison. Also, be sure to examine the number of concurrent connections that can be supported and any options for user management, especially in the case of a host-to-gateway VPN.

To discuss what makes a VPN device perform, let us pretend that we are going to make our own VPN box. This may not be an entirely philosophical discussion. When you open the lid, you will see that most VPN devices are just repackaged computers running on a UNIX or even Linux platform with a nice GUI (graphical user interface). There is nothing stopping you from building the same on your own.

The first item on the shopping list is the network interface card (NIC). Nothing will affect the performance of a VPN device like a NIC that supports hardware encryption. The process of encryption and decryption is cumbersome on a CPU that is also responsible for many other functions in a general-purpose computer. Even the occasional interrupt to another process will slow the encryption process. An NIC with built-in VPN support performs the processor-intensive mathematical transformations involved in encryption in hardware. This is not only always faster than software encryption, but it also frees up the CPU of the gateway device itself for other functions.

Once the hardware encryption is considered, most other elements in the VPN box are more than adequate for common WAN connection speeds. Consider that some of the most popular VPN devices on the market can support 280,000 concurrent connections — this is on hardware that is a 600-MHz PIII, 256-MB RAM, and 40-GB hard drives. Most of these items can be found at commodity prices if you can manage to dig up a processor as "slow" as 600 MHz at an online bargain site.

Even the choice of hardware encryption cards, which can be quite pricey, may not be necessary, depending on your connection speeds. What you are primarily concerned about is how fast you can decrypt and encrypt packets. If you have a full T-1 line to the Internet that runs at 1.544 Mbps, then that is the most speed you need to squeeze out of your VPN box. I have successfully created VPN devices out of 486 processors with 128 MB of RAM that can keep up with a T-1 line. This is using 3DES encryption. Any type of modern processor (PIII 800 MHz) can easily encrypt and decrypt traffic at up to 20 Mbps. This is without any form of hardware encryption whatsoever. Unless you are encrypting traffic on the LAN at 100 Mbps or over aggregate T-1s and T-3 (45 Mbps) links or higher or plan to upgrade soon, money spent on hardware encryption cards is not necessary.