OpenVPN Support Forum

My first post here - asking for help, as I'm just about to give up.

I have two locations, connected via an OpenVPN network.

Site1 (I'll call it "source"): here sits a cable-to-IP converter (a DVB-C receiver running Enigma2 - a custom Linux version), which is in the same LAN as a Raspberry Pi 2, which acts as the VPN server. The VPN port is forwarded via the local router and is thus accessible from the Internet. The site has a 100 Mbps down / 50 Mbps up cable connection and all relevant connections (RPi2, receiver) are UTP cables via a 100 Mbps router.

Site2 (I'll call it "destination"): here sit a number of various consumer devices (PCs with Windows, Android devices etc.), all connected in the same Gigabit LAN to a Netgear WNDR3700v2 router, which is running DD-WRT v3.0-r29048 (latest and greatest). I have tested with both individual devices as well as the local router connecting as clients to the RPi2 OpenVPN server. The site is on a 80 Mbps down / 4 Mbps up cable connection and the devices are connected via either Gigabit LAN or WiFi (150 Mbps) to the router.

What works: from a machine in Site2 I can ping the DVB-C receiver and the RPi2 without problems. Streaming of SD channels works fine in all situations (no matter who the client is). Streaming of HD channels only works if the VPN client is a strong machine (it is not a video decoding issue, but a VPN one). The bandwidth used by a SD channel varies between 3 and 8 Mbps (no compression or transcoding on the raw stream). The bandwidth used by a HD channel varies between 10 and 15 Mbps.

What doesn't work: streaming of HD channels is choppy, with very short interruptions every few seconds, if the VPN client runs on the Site2 router (the WNDR3700v2 with a dual-core Atheros CPU @ 680 MHz and 64 MB of RAM). Throughout the playback, the CPU usage on the router stays within reasonable limits (~25% of the overall CPU power, so ~50% of a single core), same for the RAM. There's no difference if I'm using TCP or UDP as the OpenVPN protocol.

Question: any idea how to improve either the throughput or reliability of the transmission (i.e. either pass more data per time unit or reduce the number of retransmits)?

The VPN configs are below:

server.conf Client.conf - from a Windows 10 PC, i5 with 8 GB of RAM: client.conf from the NetGear router:

What network link do you have between Site#1 and Site#2 ?

Thanks for the answer!

It's an Internet connection - nothing particular about it (no metropolitan ring / WAN or anything).
Tested with iperf, outside the VPN:
- upload from Site1 to Site2 ~40 Mbps;
- upload from Site2 to Site1 ~4 Mbps (poor upload at Site2, but then I guess it's not really relevant other than for the ACKs going back to the source)

I don't think it's the network, because on the very same network connection the HD transmission works great when the client (in Site2) is a relatively powerful box. The problem arises when the client is the router in Site2 - and even then, it's not really breaking the transfer, but just stuttering from time to time.

Download the source and then stream it yourself.

Kind of hard, considering it's a live TV broadcast...
Are there any "magic" options which would improve the performance of the data transmission over VPN?

OpenVPN is working perfectly .. your internet connection is at fault.

Remove all sndbuf/rcvbuf, all socket-flags and all mtu related, also tun-ipv6.

Use "proto udp"
Disable encryption on data channel "cipher none"
Disable compression "comp-lzo no"

Test again.

Traffic wrote:OpenVPN is working perfectly .. your internet connection is at fault.

I thought the same - and there are times when it's working really bad indeed.
But then how come I only get the stuttering when the VPN client is running on the router? I have zero stuttering when the VPN client is on the PC. Tested with more-or-less identical configuration, one minute apart, on the very same stream - no stuttering when connecting with the client from the PC, stuttering when connecting with the client from the router.

Your router is suspect to not have enough throughput.
Try to reduce amount of transferred data and CPU load.
See my suggestion.

Pippin wrote:Remove all sndbuf/rcvbuf, all socket-flags and all mtu related, also tun-ipv6.

Use "proto udp"
Disable encryption on data channel "cipher none"
Disable compression "comp-lzo no"

Test again.

Did so.
Setting "cipher none" fixes the stuttering issue. So my guess is then that the router is not capable of decrypting the incoming packets fast enough...
But then I don't really need a VPN, do I? If none of the traffic is encrypted - I can as well have port forwarding at router level and access the remote ends over the 'net.
Unless I completely misunderstand the way this thing works, someone can eavesdrop on an unencrypted VPN connection and extract the whole traffic, correct?

airwave wrote: not capable of decrypting the incoming packets fast enough...

Yup.

But then I don't really need a VPN, do I?

For you to decide
This was a test to see if the router was the culprit.

Unless I completely misunderstand the way this thing works, someone can eavesdrop on an unencrypted VPN connection and extract the whole traffic, correct?

Packets are still being authenticated but not encrypted. Traffic? Hit me if I'm wrong
But now you can try to use the standard cipher, do not write "cipher" in config, which is faster and see if router can handle that.

Another thing you could try is to add "fast-io" on both sides.
So, try to optimize the thing, a nice learning experience (for me too)

comp-lzo can have a negative effect because already compressed data will grow in size when compressing again and it costs CPU load. zip a zip file and compare size.

OK, so I've spent the last couple of hours testing every single cipher available on both the RaspberryPi OpenVPN server and on the WNDR3700v2 client with the latest DD-WRT build.
There aren't so many in fact, as the RPi package only supports 16 ciphers and three of those are CAMELLIA-based - which the DD-WRT doesn't support.
In the end, it turns out that no matter what the key length is, whether the key is fixed or variable, what algorithm is used, the router simply cannot cope with decrypting sustained ~12 Mbps UDP traffic. The only way it works is by turning the cipher off altogether, which I'm not that excited about, as it basically defies most of the purpose of having a VPN in the first place.

Future steps - either I find some more powerful end-device (I tested it with an Atom-based quadcore stick - MeegoPad T02, if anyone is interested, steer clear as it cannot do the HD playback properly even without the VPN overhead, and with an Amazon FireTV Stick, which still has some hiccups when playing HD content via Kodi and the VUplus plugin), which could do both the VPN part and the HD playback by themselves (thus pulling the router out of the discussion) or I buy a better router.

@Pippin - removing the cipher option altogether makes OpenVPN default to BF-CBC, which does indeed allow for lower CPU usage (~25% in total compared to ~30-35% with other ciphers), but the playback is still choppy even on a powerful end-device (Windows desktop PC).

Getting off-topic but take a look at Slingbox too.