This chapter is from the book
This chapter is from the book
This chapter is from the book
Performance
VPN performance depends on many factors, including the type of VPN package you are using, the operating system you are using, the hardware it runs on, and so forth. This section will discuss techniques you can use to measure server and network performance of your VPN components.
Server Performance
Server performance should be periodically reviewed to make sure the machine is not throttling under the load of the VPN. The easiest way to gather information on how your server is performing is to use tools like top and vmstat.
The top command can be used to give you a real-time estimate of what each process on your system is doing. The following is part of a listing from the output of top:
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
485 root 9 0 3096 2500 2436 S 5.0 4.0 0:00 VPN-PROC
23713 root 18 0 1016 1016 812 R 0.9 1.6 0:00 top
23699 root 10 0 1068 1052 884 S 0.1 1.6 0:00 sshd
1 root 8 0 160 128 108 S 0.0 0.2 0:04 init
2 root 9 0 0 0 0 SW 0.0 0.0 0:00 keventd
3 root 9 0 0 0 0 SW 0.0 0.0 0:55 kswapd
4 root 9 0 0 0 0 SW 0.0 0.0 0:00 kreclaimd
5 root 9 0 0 0 0 SW 0.0 0.0 0:09 bdflush
6 root 9 0 0 0 0 SW 0.0 0.0 0:03 kupdated
Here we can see that the system is relatively idle. The process VPN-PROC represents a VPN process; watching it as clients begin connecting to your machine can give you an idea of how many clients your server can handle.
To collect utilization statistics, you can use cron to schedule the vmstat command to run at regular intervals during the day.
Network Performance
In most cases, VPNs will perform worse than an identical network without a VPN because VPNs must encrypt and decrypt the data. (The decrease in performance can potentially be mitigated if your VPN solution compresses traffic—for example, the IPCOMP protocol in IPSec.) When testing your VPN solution, it is a good idea to see how it performs over time.
Some VPN technologies give you different choices that might affect performance. You might find that one encryption cipher outperforms others on your hardware. In general, the weaker the encryption, the faster it is. However, you might find that some strong ciphers outperform weaker ciphers. (We discuss cipher-related issues in Appendix B, "Selecting a Cipher.")
Over time, your VPN performance will change, perhaps because new users are added, network needs are different, or your hardware starts failing. It would behoove you to have an idea of how your VPN performs now and has performed in the past, before your users start complaining.
To view your current network usage, you can use a number of tools. Our favorite is the Multi Router Traffic Grapher (MRTG). We will also describe how you can use ttcp to gather some simple network performance measurements.
MRTG
Before you bring your VPN into production, you should first understand the amount of bandwidth currently in use for user traffic. An excellent lower-level tool for monitoring bandwidth is MRTG.
MRTG is a free tool that produces graphs on your current network traffic in addition to weekly, monthly, and yearly graphs. It uses SNMP to gather utilization statistics from interfaces on servers and routers. MRTG shows only bandwidth utilization; it does not show a breakdown of utilization by traffic type, such as SMTP traffic or web traffic.
Tightening up SNMP Security
Although SNMP on a gateway device can be considered a security risk, it can be useful to have it enabled for monitoring certain types of events. To tighten the security on SNMP, you can take the following steps:
-
Make your community string read-only. This prevents outsiders from making changes to devices even if they have the community string.
-
Create a firewall (or access list) entry, preventing SNMP traffic from entering from the Internet.
-
Make sure to change the default community strings. They are often "public" for the read-only string and "private" for the read-write strings. In SNMP, these strings are treated as passwords and should be changed regularly, just like any other password.
After you have gotten an idea of your normal bandwidth utilization, you should try connecting to your Linux server with a single VPN client. Just as you did when measuring the server performance, you will use this client connection as your baseline bandwidth requirement.
Again, as with server performance, make sure you do this for each type of connection that your server will be initiating. Once the server is in production, MRTG can be used to monitor your VPN interfaces, such as an ipsec, tun, or ppp. This will give you a good idea of your current utilization trends.
ttcp
To get a rough estimate of what kind of overhead the VPN will have on your traffic, you can use the ttcp command and compare throughput.
Using VTun as an example, we first measure the normal throughput. We will send some data (in this case, the Linux kernel sources) over and measure its performance. First, we test the connection between the two VPN machines, Bears and Falcons, using their public IP addresses. This tests the actual connection of the machines without any of the VPN overhead. The non-VPN IP addresses we are using are 280.8.8.8 and 270.7.7.7.
bears# ./ttcp -t 270.7.7.7 < ../linux-2.4.12.tar.bz2 ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp ->192.168.1.2 ttcp-t: socket ttcp-t: connectttcp-t: 21508430 bytes in 26.00 real seconds = 807.94 KB/sec +++
The last line of the output gives us a throughput of 807.94 KB/s. Next, we run the same tests but use the VPN IP addresses this time, 192.168.1.1 and 192.168.2.1. By using these addresses, we will be sending data over the VPN.
bears# ./ttcp -t 192.168.2.1 < ../linux-2.4.12.tar.bz2 ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp ->10.0.0.2 ttcp-t: socket ttcp-t: connectttcp-t: 21508430 bytes in 29.59 real seconds = 709.78 KB/sec +++
As you can see, the throughput this time is 709.78 KB/s. There is a throughput loss of almost 100 KB/s due to VPN overhead. The numbers you receive in your testing will vary, but you get the idea. You can get ttcp from www.mentortech.com/learn/tools/tools.shtml.