Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have a VPN setup between a remote office with 2 ADSL connections (8Mb downstream, 512Kb upstream) and a main office with a 10Mb EFM connection (10Mb both up and down).

The VPN is an IPSec connection using a DrayTek 2930 router for the ADSL and a DrayTek 3200 router at the EFM end. However, I'm unable to get speeds over this connection (tested with iperf) of anything over 600Kb or so down from the main office (traffic will pretty much always be from the main office to the remote office)

Whilst I realise that there is an overhead and I'm never going to get the "full" bandwidth available over this VPN, I'd like to think that there's something I should be looking at that may help improve it.

I've tried using the DrayTek's built-in "VPN Trunking" features which are supposed to load-balance connections, but this doesn't seem to improve matters much.

I guess my question is - is this the kind of performance I should expect from this kind of setup and I'll just have to live with it, or should I be able to squeeze something more out of it through some VPN magic?

share|improve this question
There are way too many variables here to give more than wild speculation. What can you realistically get using iperf without the VPN? What are you actually testing with iperf? What sort of VPN is it? What hardware is it running on? What are the performance statistics of that hardware? Is the network, the hardware, the protocol, or something else the bottleneck? –  womble Apr 27 '12 at 14:54
I know - I realise it's such a wide open question, I was probably just looking for things to look at, and an opinion of what kind of performance a well-setup VPN over a normal ADSL connection should get in ideal conditions. The iperf test has a server at the EFM end of the VPN and a client machine at the ADSL end, just running a simple iperf -c w.x.y.z from the client. –  David Heggie Apr 27 '12 at 14:56
Under ideal conditions, a good VPN should be within noise of full link speed. –  womble Apr 27 '12 at 15:12

2 Answers 2

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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.