Just how slow should my VPN be?

The problem is many cheaper routers with VPN server/clients cannot actually use the VPN functionality at wire speed (or even at full WAN speed).

I used to administer an organisation where the head office had a Draytek Vigor 2950 at head office originally connected to a 2Mb service which we upgraded to 50Mb. It typically had 10-15 remote sites connecting using Draytek Vigor 2800/2820's.

When we upgraded to 50Mb, we found sites we still unable to use more than around 2Mb of VPN bandwidth. I used my home pc as a VPN client to connect using a 10Mb connection and still saw similar results.

Then I replaced the head office 2950 with a pfSense router with 2 x Xeon p4's and suddenly found much more VPN bandwidth - redoing the same test with my home pc suddenly yielded pretty much near the full 10 Mb of bandwidth available to me to test with.

I intended to then test the 2950 with some 2800/2820's on the bench but with the improvement I saw once the 2950 was replaced with a pfSense I saw no point in persisting to use the 2950. The site 28*0's saw some speed increase but the sites with faster (over 10Mb) connections still could not make full use - I suspect due to limitations with the 28*0.

After doing a little more investigation I discovered a command to benchmark my pfSense router from the command line which showed the encryption throuughput would vary massively on packet size. I suspect the claimed 90Mb VPN throughput of the 2950 was using massive packets never to be seen in the real world although to be fair Draytek are not the only vendor guilty of such practises. If you can change your packet sizes with iperf I wouldn't be surprised if you can see differences.

Once you've considered whether your devices are powerful enough to sustain a VPN tunnel at speeds you hope for, the next step would be to consider WAN optimisation devices if your budget allows. There are devices made by the likes of Riverbed Technologies and Cisco that make efforts to reduce actual traffic sent over the VPN while causing no apparent difference at either end.

Also with your Drayteks you can try and enable vj compression to see if this helps.

You need to benchmark, and monitor as much as possible during your tests to find the bottleneck.

• Run an iperf test between sites over the same links without any VPN enabled. This will give you a baseline.

• What is your round-trip-time via ping? You may need to use the -W parameter of iperf to increase the TCP window size, as it defaults to 8k fixed, which limits throughput on anything but a local LAN. Read up on bandwidth-delay product. In normal operation, modern OS adjust the TCP window size on the fly, but iperf overrides this behavior and defaults to an 8K TCP window.

• Ensure that you are not blocking ICMP packet-too-big messages either inside or outside the VPN. You also have to make sure that routers are properly generating these ICMP messages; they are vital for TCP throughput. Both your DSL and the IPsec tunnel itself will limit the maximum packet size that you can handle to something far less than 1500 bytes. Also make sure you are not fragmenting packets with the do-not-fragment bit set on any of your devices.

• Disable any link-load balancing for your tests, using only one link. Depending on the implementation, these can cause reordered packets and kill TCP throughput. If you re-enable load balancing after getting good throughput on one link, you probably only want to load-balance on "source-destination IP pair" if that is an option, do not select "per-packet load balancing".

• Things to monitor during your tests: link utilization as seen by the routers, CPU on hosts and routers, interrupts/sec, packet drops per second, interface errors if any.

• I assume your routers are doing all the IPsec in software, and do not have crypto offload. As such, choose AES-128 and SHA-1 as the crypto algorithms for the IPsec tunnel; these use about 20% of the CPU as compared with 3DES+SHA-1 in software.

• Disable all other functionality on the routers, such as IDS/IPS scanning, antivirus scanning, web filtering, etc. These can hog enormous amounts of CPU or cause queuing delays.

• Watch out for bufferbloat, and reduce any over-sized router buffers you can configure to something realistic based on your observed ping times.

• Test after business hours to ensure you are not fighting with normal traffic.

You should be able to get within 10-20% of your non-VPN baseline test when using IPsec with AES-128 and SHA-1, assuming everything is working properly.

Just reading this a few years later. :) The bottleneck seen by the original question is from the 512kbps upload speed limit at the remote end where the VPN server is.

For example, if you connect from a laptop (regardless which VPN protocol you use) to a remote site's VPN and you then do a speed test using speedtest.net from your laptop, all of that speed test traffic is travelling through the VPN tunnel. And because the remote system is capped at approx 512kbps "upload" speed on it's end, you will not see more than that in "Download" speeds on your laptop's end. To you it is a Download, but from the remote site it is Uploading the traffic to your laptop through the VPN tunnel. And as we've already established the remote side has a 512kb upload speed limit. Clear as mud?

You are actually getting pretty good speeds if getting 600kbps since that is more than the 512kbps upload rating at the remote site.