I've just finished setting up a VPN'ed NAS with my newly acquired un-overclocked Raspberry Pi Model-B and I've run into something I can't find an answer for elsewhere.

The internet bandwidth, as determined using

wget --output-document=/dev/null http://speedtest.wdc01.softlayer.com/downloads/test500.zip

is much slower than what I'd expect to get. I'm getting around 1.34 MBps on my Pi through ethernet when I'm getting close to 7MBps when the ethernet is plugged directly into my laptop.

The problem is with OpenVPN, but I can't figure what exactly it is. Here's how I know this.

I compared the download rates on the Pi with the VPN turned off and on -- it was 5.03 MBPS vs 1.34 MBPS.

Then I tried it on my laptop (wired) -- it was 6.9 MBPS (perfect) vs 6.7 MBPS (near perfect).

So the fault doesn't lie entirely with my VPN service (PrivateInternetAccess) which gives a 3% reduction in bandwidth on my laptop -- but has to do with the way OpenVPN runs on the Pi which gives a 74% reduction in bandwidth.

Any ideas on why OpenVPN on Raspbian is being so terrible?

UPDATE: Most of that reduction from 6.9MBPS on the laptop without VPN to 5.03 MBPS on the Pi without VPN seems to be from the SD card write speed, which I've determined to be around 4.9MBPS. It's that huge reduction from 5.03 MPBS on the Pi without VPN to 1.3MBPS with VPN that needs to be explained.

UPDATE 2: Some more clues from suggestions from the comments: 1) OpenVPN utilizes 70% of the CPU when it is running and wget is in the background 2) On the Pi, I get 1.34 MBPS from a US VPN server and around 500-600 KBPS from ALL European VPN servers, BUT on my laptop,I get 6.7MBPS from the US VPN server and a very similar 6.6MBPS from some European servers like the one in Netherlands. What I'm saying is that distance to the server seems to disproportionately affect the Pi rather than my laptop.

  • It could be a combination of poor write speed and VPN overhead. I never liked to use VPN's because they were just slow over internet and SSH tunnelling was always the fastest. Are there any options for enabling compression on OpenVPN? Possibly play with that, maybe on the fly encryption causes issues. It is a good question. I am also interested in the answers in relation to the Pi
    – Piotr Kula
    Commented Jan 24, 2013 at 8:45
  • Look at the CPU load with top while testing, that should say something about the encryption overhead.
    – Frepa
    Commented Jan 24, 2013 at 9:27
  • @Frepa Excellent suggestion! When the VPN is enabled, OpenVPN utilizes 70% of the CPU. Do you think this is what's causing the huge difference in transfer rates?
    – dbrane
    Commented Jan 24, 2013 at 18:20
  • @dbrane, it sounds as if CPU is the limiting factor. Where does the remaining 30% CPU-time go? Idle? From update 2 it sounds as if network latency (i.e. not only throughput) is important for the performance. Maybe there is some hand-shaking going on in VPN.
    – Frepa
    Commented Jan 24, 2013 at 19:00
  • @Frepa Most of the remaining CPU-time is used by wget itself, which is the command I use to test the transfer rate. Everything else in the list uses less than 1% each. I'm using a CA certificate with the VPN, if that information helps. Maybe I should try overclocking and see if that helps?
    – dbrane
    Commented Jan 24, 2013 at 20:27

1 Answer 1


On low-powered devices, at least when using SSH, I've had good experience using the RC4 cipher to improve performance since it's computationally faster, so uses less CPU for the bandwidth/allows higher bandwidths for the same CPU usage. This guide explains how to change the cipher to any one supported by OpenSSL - like RC4:


Note that RC4 is not the most secure algorithm available, but SSL still uses it in secure ways (which exist, as described here: http://en.wikipedia.org/wiki/RC4). Update: this is less true now than in the past. Trust in the security of RC4 is reducing even more, as techniques for breaking it advance, and 2013 has given us various progress in breaking RC4 and speculation about the NSA having managed. Quoting Wikipedia:

As of 2013, there is speculation that some state cryptologic agencies may possess the capability to break RC4 even when used in the TLS protocol.[3] Microsoft recommends disabling RC4 where possible.[4][5]

So, can I still recommend RC4? Not really in general. Of course you need to tradeoff security and performance, and maybe you don't actually need lots of security — any cryptography, even RC4, will still slow down dragnet surveillance efforts like the ones from NSA. But I would be really careful with actually sensitive data, and change algorithm to something else if possible at all (I've started to benchmark my Raspberry to look for fast alternatives).

Update 2: on my (overclocked) Raspberry, AES is not so slow, if you have enough CPU available. The table below shows that RC4 can crypt ~57MB/s, while AES-128-CBC can crypt ~21.4MB/s. Of course, this does not explain why you get such bad performance — but maybe you're using by default a slower cypher, or maybe there's some other inefficiency which could be improved.

$ openssl speed rc4 aes
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
rc4              45281.36k    54782.67k    57196.80k    57391.48k    57570.77k
aes-128 cbc      17904.15k    20469.38k    21133.95k    21449.62k    21403.72k

Overclocking settings from /boot/config.txt:


# for more options see http://elinux.org/RPi_config.txt
  • 1
    Any type of encryption (ssh/vpn) will cause additional CPU usage, which is probably your bottleneck.
    – earthmeLon
    Commented May 20, 2013 at 23:27
  • 1
    My point was that RC4 uses less CPU than other ciphers, so it might be good in this situation. But I'm not sure whether you agree or disagree with my answer. Commented May 24, 2013 at 13:34
  • @earthmeLon: I updated my answer to state my point explicitly, because it was anyway unclear. Not sure that addresses your comment. Commented May 24, 2013 at 13:36
  • Absolutely. I was very appreciative to know that RC4 is a good solution with minimal overhead, because of SSH2's implementation of it. Thanks for the information :D. Too bad you couldn't see I gave you an upvote, eh?
    – earthmeLon
    Commented May 25, 2013 at 3:31
  • Indeed — I only noticed later that your comment coincided in timing with the upvote. Thanks! Commented May 25, 2013 at 4:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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