Networking

Factors that can boost VPN performance

With so many VPN connections on networks today, security and interoperability are starting to take a back seat to performance. These insights into the factors that affect VPN performance will help you get the most out of your VPN connections.

As� virtual private network connections spread, VPN performance joins security and interoperability as a primary administrative concern. If you need to add bandwidth to your VPN connection because of performance issues, how much would you need in order to achieve a good balance between security and performance? While every situation is different, a good background on what determines VPN performance can help you maximize that performance without compromising security and interoperability. I’ll explain how various factors can affect your VPN performance and some of the options you have for increasing that performance.

VPN performance is an increasingly important issue
Many of today’s VPN products emphasize security and interoperability, with performance a lower priority—and rightly so. A VPN is usually set up with security as one of the primary goals, and in many cases, VPNs need to be able to interoperate among different vendors, so interoperability is also a key factor. However, performance is becoming more important as VPNs become more prevalent on corporate networks.

VPN types
In general, there are two types of VPNs—remote client VPNs and site-to-site VPNs. A remote client is generally a single PC that uses VPN software to connect to the host network on demand, while a site-to-site VPN is generally a permanent connection between two sites using dedicated networking equipment. A remote client VPN typically supports telecommuters, while the site-to-site variety usually connects office networks.

Some key factors that affect VPN performance
If your VPN seems slow, or you just want to know how efficient it really is, you have a number of options for improving its performance. Let’s look at some of the factors involved.

My lab setup
For the purposes of this article, I’ve set up a Windows 2000 Server with VPN services enabled via Windows 2000’s built-in Remote Access Services. On the remote client side, I’m running a Windows XP Professional workstation over a 1 Mbps DSL connection. This connection uses Point-to-Point Tunneling Protocol (PPTP) to connect to the central server. My lab network uses Network Address Translation (NAT) to get out over the DSL connection to the Internet.

PPTP vs. L2TP
While more widely supported than Layer 2 Tunneling Protocol (L2TP), PPTP is giving way to L2TP as the tunneling protocol of choice because of L2TP’s enhanced security features. However, establishing an L2TP VPN is somewhat more complex that setting up a PPTP connection. PPTP-based VPNs may also operate slightly faster because there is less processing involved in encrypting and encapsulating the packets. Under PPTP, the PPP (point-to-point protocol) payload packet is encapsulated inside a GRE (generic routing encapsulation) packet, which is then encapsulated inside an IP packet to which the data link header is attached. The packet is then sent across the tunnel.

Under L2TP, packets are encapsulated no fewer than four times and as many as six times, depending on the IPSec policy being used. Each time a packet is processed, overhead is added to the overall procedure, resulting in higher latency. I’d be remiss if I didn’t mention that L2TP provides additional levels of security through the use of DES and 3DES encryption as well as data authentication. However, if you’re looking at a VPN from a strict standpoint of performance, L2TP may not be the best choice.

One point worth mentioning is the fact that PPTP relies on the TCP protocol, while L2TP uses UDP for typical communication. This can result in slightly lower performance capabilities for PPTP. Bear in mind, though, that since PPTP uses fewer levels of encapsulation, the total message size is smaller than with L2TP, which would tend to cancel this advantage.

What kind of VPN are you using?
The topology of your VPN can also have a significant impact on its performance and can vary widely among the remote devices. If you’re supporting a site-to-site VPN that connects two different remote offices, it’s likely that both ends use dedicated equipment configured for a permanent VPN tunnel. If your VPN performance seems slow, you may need to increase the size of the tunnel by adding bandwidth at both ends. You might also be able to change configuration options to increase performance.

For example, if your tunnel allows a maximum of 50 users but all 50 of them don’t need to use it all day long, you can decrease the maximum number of clients allowed to preserve bandwidth. You can also use traffic monitoring software to determine the type of traffic that is traversing the VPN. You’ll need to place a system running such software between your users and the VPN, since the VPN traffic is likely to be encrypted.

Watch your traffic
Traffic monitoring software can help you to tweak your policies with regards to your infrastructure. For example, is there a lot of file sharing traffic coming across the VPN link? If so, put a stop to it by enforcing a stricter administrator policy on file sharing among users. If there is excessive replication traffic coming across the link between Windows domain controllers, consider changing the replication interval between the two machines.

What about DNS and DHCP? Are these services hosted at the central site or at each location? If they are centrally served and you’re having performance issues, consider separating these services and placing them closer to the users who need them.

The next steps
When all is said and done and you’ve tweaked everything you can to increase performance, you may need to consider replacing the VPN concentrators. Most VPNs tell you how many tunnels they can support. As you begin to approach this number, the system may not have the capability to keep up with the processing requirements.

On the other hand, if you have a VPN for which there is a central VPN server or VPN concentrator, and VPN connections are created on demand directly from remote user workstations, you have different things to try. First, if a user with a dial-up connection complains that the VPN is slow, the reason is obvious. Unless it’s for e-mail only or for a low-bandwidth application, a dial-up connection to a VPN just won’t cut it.

Second, make sure that the remote user’s PC is capable of handling the load. Bear in mind that in this type of VPN, the workstation is responsible for establishing, maintaining, and using the tunnel, as well as for encrypting and encapsulating data, which can tax a CPU, depending on the level of encryption. If you simply want to enhance performance for these machines and you aren’t concerned about security, you could disable encryption, which would increase the overall performance of the VPN.

In this type of scenario, the VPN client included with newer versions of Windows, such as Windows XP, is capable of telling you what kind of compression you’re getting (Figure A). Compressing data definitely helps with the performance of the actual link for the VPN, but it can spell trouble if the client machine doesn’t have the CPU resources to handle the compression as well as all of its other duties.

Figure A
VPN status under Windows XP


A simple test of VPN performance
Because of their complexity and the huge differences in technology between different types of VPNs and different vendors, it’s difficult to determine the actual efficiency of a VPN, let alone improve it. The simplest method is to determine the actual size of the tunnel between two sites, clock the average file transfer speed between the sites, and take the ratio as a percentage. You’ll never achieve 100 percent efficiency—that would imply a perfect VPN with no overhead, which is impossible.

For example, if you have 1 Mbps of bandwidth dedicated between two sites and you get 800 Kbps of raw throughput, your efficiency would be 80 percent. From there, you can begin to assess some of the factors I’ve discussed to determine where you can make improvements.
0 comments