VPN Designs

After you have weighed the VPN components necessary for your VPN implementation, you'll need to take a look at the layout of your VPN design: what devices need VPN functionality (servers, routers, firewalls, PCs, and so on), what type of VPN functionality they need, and what connectivity is required. This information will greatly assist you in picking a suitable VPN implementation, and will bring up any design issues and problems you should consider before making a final choice.

The following sections discuss some VPN designs, and some issues to consider when using VPNs in your network. Specifically, the section covers the following:

Connection Types

From a design perspective, this section will cover the various types of basic connections that VPNs use. These connections include point-to-point, hub-and-spoke, and fully meshed.

Point-to-Point

There are two basic types of VPN point-to-point connections:

Device-to-Device Connection

A device-to-device VPN connection is a user-to-user VPN type, where only two devices are involved in the VPN. This connection type is usually deployed where only a specific type of traffic between two devices needs to be protected. An example of device-to-device connection includes backing up the configuration file on a Cisco router to a TFTP server, sending SNMPv2 traffic from a managed device, like a Catalyst switch, to an SNMP management server, or sending logging traffic from a PIX security appliance to a syslog server.

One concern of device-to-device connections is that they place an extra burden on the VPN endpoint device. For example, imagine that you have a syslog server that has to handle logging information from 200 devices. In this situation, the syslog server would have to terminate 200 VPN device-to-device connections, which might place an undue burden on it. This is shown in the top part of Figure 1-8.

Figure 1-8. Device-to-Device and Network-to-Network Connections

 

Network-to-Network Connection

A network-to-network VPN connection would be considered an L2L VPN type. With a network-to-network connection, two VPN gateways provide protection of traffic between two or more networks. One advantage this type of point-to-point connection has over a device-to-device connection is that traffic from more than one device can be protected via the same VPN connection. Plus, you can choose an appropriate VPN gateway device to handle the VPN traffic overhead and processing, offloading this from endpoint clients. The middle part of Figure 1-8 shows a network-to-network connection type.

I'll re-examine the one concern from the last section, in which 200 devices are sending logging messages to a central syslog server. Instead of terminating the VPN connections on the syslog server itself, you could put a VPN gateway device in front of the syslog server and set up remote access connections to the VPN gateway, which would be responsible for processing the VPN traffic from the remote devices. This would be a hybrid point-to-point connection. It is shown in the bottom third of Figure 1-8 (device-to-network).

Fully-Meshed

A fully-meshed VPN network has each VPN device or network connecting to each other's VPN device or network. The left-hand part of Figure 1-9 shows an example of a fully-meshed design, connecting multiple networks to each other.

Figure 1-9. Fully- and Partially-Meshed VPN Network Designs

One advantage of this design is that a device or network can send traffic directly across a VPN to a remote destination without having to go through intervening VPN connections. However, the main disadvantage of this solution is scalability. For example, in Figure 1-9, as you add more sites, you're increasing the number of VPN connections on a device at each site. This increases the processing required on the VPN devices and scales poorly.

Partially-Meshed

A partially-meshed VPN design addresses the disadvantages of a fully-meshed VPN design. With a partially-meshed design, not every VPN device has a VPN connection to other VPN devices. One example of this design is a hub-and-spoke design, shown in the right-hand part of Figure 1-9. This is a very common design in corporate networks. The hub is typically the corporate site and the spokes are the remote office sites. This design works well when the spokes need to communicate with resources located at the hub; however, this design doesn't scale well when one spoke needs to send data to another spoke. In this instance, the traffic has to be protected twice, and must make an extra hop, adding latency to the traffic, and additional overhead on the hub device. You could overcome this issue easily by adding a point-to-point VPN connection between the two spokes that constantly need to communicate with each other.

VPN Considerations

When designing a VPN solution, there are many factors to consider to create a suitable solution for your network. Some of these factors include the following:

The following sections will cover these factors.

Protected Versus Unprotected Traffic

One of the factors you'll need to consider is whether or not traffic needs to be protected when sent between two devices that have a VPN connection currently set up. Some things to consider are the amount of traffic protected and whether or not it is necessary to protect the information (the security sensitivity of the information).

For example, assume that your VPN device supports VPN processing at 5 Mbps. However, the amount of VPN traffic sent to your device is 6 Mbps. Unfortunately, you'll have a lot of performance problems on your VPN device. To solve this problem, you could set up a feature called "split tunneling," which sends some traffic protected and some in clear text.

In the example of the 1 Mbps performance difference (5 Mbps is the processing limit, but 6 Mbps is received), you would need to evaluate what traffic actually needs to be protected. Perhaps 2 Mbps of this traffic is web traffic and you've decided that it is not necessary to protect this traffic. You could set up a split tunneling policy that would protect all traffic for the VPN connection except for the web traffic. Therefore, your VPN device would have to protect only 4 Mbps, which is manageable by your device's 5 Mbps VPN performance.

Tip

To determine what should and shouldn't be protected, you'll need to examine your company's security policy. For remote access clients, I highly recommend that the client use a client-side software firewall to protect against attacks that are related to the unprotected traffic.

 

Fragmentation

When I see performance problems with VPN implementations, the first thing I look at are issues with fragmentation. Administrators commonly forget to factor in the overhead that VPNs add to packets, and that fragmentation might occur because of this overhead.

For example, assume that you have a database application sending data across a VPN connection. The devices involved use an MTU size of 1,500 bytes. On average, the data sent use up most of this. On top of this, the VPN adds another 80 bytes of overhead, commonly causing the necessary MTU size to require 1,580 bytes. However, the VPN device supports a maximum of 1,500 bytes for the Ethernet segment to which it is connected. In this instance, the VPN device has to break the original packet into two packets.

Most people would think that this process would introduce some, but not a lot of, overhead to the VPN device; however, in many cases, it will kill the performance of the device because the VPN device now has to protect twice the number of packets!

Therefore, when looking at a particular VPN design and VPN type you'll use, you'll need to consider fragmentation issues. To prevent fragmentation, you'll need to examine the VPN implementation to see the amount of overhead that it will add to packets, and then determine what MTU size the client devices are originally using. You'll either need to implement a dynamic MTU discovery process, such as path MTU discovery (PMTUD), that will adjust the MTU size to an appropriate size to prevent fragmentation, or manually adjust the MTU size. For example, if the MTU size of the client is 1,500 bytes and the VPN overhead is 80 bytes, you'll need to make sure the client devices originating the data have their MTU size decreased to 1,420 bytes. I discuss troubleshooting of fragmentation problems in more depth in Chapter 19, "Troubleshooting Router Connections."

Fragmentation Surprise

I once was hired by a company to help them with their current VPN implementation. They relayed to me that when they put the VPN implementation in place, their performance dropped to unacceptable levels; and when they removed their VPN configuration, the problem disappeared. Their assumption was that the processing required to protect the traffic overwhelmed their 3620 router with a VPN network module (NM) installed. I learned that they were only trying to protect about 2 Mbps of traffic, and that the VPN-NM should have been able to handle this amount of traffic easily. My immediate suspicion was that their problem had nothing to do with the VPN protection function, but with fragmentation. Apparently clients at the site were using an MTU size of 1,500 bytes and most of the data transmitted across the VPN was fairly large; and when you added the overhead of the VPN to this, about 60 percent of their packets were being fragmented, meaning that the 3620 had to not only perform fragmentation and reassembly, it also had to protect traffic of additional fragmented packets. When examining the CPU cycles of the router, sure enough, the problem was related to fragmentation. I had the administrators adjust the clients' MTU size to a smaller value manually, thereby alleviating any fragmentation issues. This made the administrators very happy, because they were worried that they would have to explain to their boss that they had bought an under-powered router and would have to spend more money on a more powerful one.

 

Application Types

As I mentioned in the first consideration section, "Protected Versus Unprotected Traffic," you might not want to protect certain kinds of traffic based on the amount of traffic you are transmitting. And as I mentioned earlier in this section, you'll need to examine your security policy to determine what types of traffic you don't need to protect.

Some application types actually don't necessarily need protection, like HTTPS and SSH. They don't need protection because a protection function is built into them. Therefore, protecting this traffic again just adds additional processing to your VPN device. Because of this, you might want to exclude this traffic, and other already protected traffic, from traversing your VPN.

Another thing to consider is whether or not the VPN implementation you choose can actually protect the traffic you need it to protect. For example, SSL VPNs protect web traffic (HTTP) very well, but were not really designed to protect other types of traffic, such as SMTP, TFTP, FTP, Telnet, and others. SSL is discussed later in the "VPN Implementations" section. After determining what traffic needs to be protected, you'll need to choose a VPN implementation that will protect this traffic adequately.

Traffic Protection

After you have decided what traffic needs to be protected, you'll need to determine how it should be protected. This information should be defined in your company's security policy. For example, if your policy states that you should be implementing encryption and packet integrity checking for sensitive information across public networks, you'll need to determine the encryption algorithm your VPN should use, and the hashing function. In some cases, the more secure solution you implement, the more processing overhead this will add to your VPN device; you'll need to carefully weigh the processing overhead and latency that the VPN feature adds compared to the additional security you'll gain from the featurethere's always a trade-off. For example, for delay-sensitive traffic such as voice and video, you'll probably spend a lot of time picking and testing various VPN protection methods to ensure that you don't experience connectivity problems for your multimedia traffic. For more information on protection types, see Chapter 2.

Address Translation and Firewalls

Some VPN implementations cause problems when trying to transmit their information through address translation or firewall devices. The following sections discuss these two issues, starting with address translation.

Address Translation Issues

With address translation, the address translation device can translate one IP address to another and, possibly, one port number to another. Mapping one IP address to another is commonly referred to as network address translation (NAT); mapping multiple IP addresses to one IP address and differentiating them by different source port numbers is commonly referred to as port address translation (PAT) or address overloading.

I'll use IPsec to illustrate the problems you might have if your VPN traffic must travel through an address translation device. IPsec has two protocols it can use to transmit data between VPN devices: authentication header (AH) and encapsulation security payload or protocol (ESP). Don't worry about the actual details of these protocols, because I'll discuss these in Chapter 3, "IPsec." Here in this current chapter, I'll discuss these protocols only as they relate to address translation.

AH provides only packet integrity checkingit doesn't perform encryption. And with packet integrity checking, a hashed value is created based on almost all of the fields of an IP packet, including the source and destination IP address fields. Imagine that this packet is traveling through a network with an address translation device. When an address translation device performs NAT or PAT on this packet, it would corrupt the packet integrity signature contained in the packet: with NAT, the address translation device changes an address in the IP header, and with PAT, it changes a port number in the TCP or UDP segment header. Therefore, AH breaks when any type of address translation is performed on its packets.

ESP provides both encryption and packet integrity checking; however, how packet integrity checking is computed is different from AH: the outside IP header is not included when creating the digital signature for the packet integrity check value; therefore this packet can be processed by an address translation device performing NAT. There is one problem, though, that ESP still has, as does AH. Both of these protocols are Layer-3 protocols. For address translation devices performing PAT, which requires information to be encapsulated in TCP or UDP segments, the address translation device won't be able to deal with AH or ESP packets (they don't have port numbers!); therefore, PAT translation breaks with both protocols.

Note

Some address translation devices now have the capability of performing PAT translation on protocols that don't have ports, like ICMP and ESP. However, this is vendor-specific and not always guaranteed to work.

Some VPN implementations deal with this address translation problem by encapsulating the VPN information in a TCP or UDP segment. For AH, this still doesn't work because the AH packet integrity check value would include this information in its computation; however, this would solve both NAT and PAT translation issues with ESP. As you will see with IPsec, Cisco supports three methods for this process, although not all Cisco devices support all of these mechanisms. The three methods are as follows:

I'll discuss these three solutions in more depth in Chapter 3, "IPsec." Remember that VPN implementations might have issues with address translation.

Firewall Issues

VPNs might also have issues with traveling through stateful filtering firewalls. A stateful firewall keeps track of the state of a connection, allowing only returning traffic for outbound connections, by default. The stateful function is based on keeping track of sessions between devices. In most cases, this only includes TCP and UDP sessions. That is because it is very easy to track TCP and UDP sessions by examining the source and destination IP addresses, and the source and destination port numbersif these values change, the change indicates a different connection.

However, not all types of traffic use a transport layer protocol. Again, I'll use IPsec as an example. When transporting data in IPsec, AH or ESP is used. Both of these protocols are Layer-3 protocols, like TCP and UDP, but don't have upper-layer information such as port numbers. AH and ESP, however, do have a special field in their headers called a security parameter index (SPI). This value is used to uniquely identify VPN connections on a device. A firewall, if properly coded by the vendor, could use this value to differentiate VPN connections when implementing a stateful firewall.

To keep track of different IPsec connections is much more difficult than I have described, however. This is very difficult with IPsec because IPsec doesn't use a single bidirectional connection for the data; instead, two unidirectional connections are used:

Remember that a stateful firewall allows outbound connections and their returning traffic, but typically denies connections that originate on the outside, like the second bulleted connection, when directed to internal devices. Special types of inspection have to be coded by the firewall vendor to deal with this scenario. Therefore, not every firewall product will necessarily be able to deal with the VPN implementation you might want to use. You'll need to examine closely the VPN implementation you'll want to use, and determine if address translation or firewall devices will create problems for your VPN.

Note

For more information on stateful firewalls, read either of my books entitled Cisco Router Firewall Security, published by Cisco Press, or Cisco PIX Firewalls, published by McGraw-Hill.

 

Redundancy

Another important component of a VPN design is redundancy. For example, if you examine the hub-and-spoke network shown at the bottom of Figure 1-9, you'll notice that this example lacks redundancy. For instance, if the hub router would fail in this design, every site would lose connectivity to every other site. Therefore, you'll need to carefully examine your network and implement a suitable redundant design, if necessary.

For solving the hub-and-spoke redundancy example, you might use something like that shown in Figure 1-10. In this design, the hub network (SiteA) has two VPN routers for redundancy, and each VPN spoke router has two VPN connections to SiteAone to each hub router. Of course, this requires special configuration on each spoke. For example, you'll probably want to ensure that not all spokes use the same hub router as the primary VPN connection; otherwise, you might overload the primary VPN router. Or you might want to actually use both VPN connections from the spoke to the hub, which would require you to configure routing correctly on both the hub and spoke routers to perform load balancing.

Figure 1-10. Hub-and-Spoke Redundant Design

On top of this, you might even need additional redundancy at the spokes, requiring dual routers. Again, this can complicate your design. Plan carefully to ensure that your design functions as desired.

Related

Категории