Tuning OpenVPN performance

Technical Support for Routers
1

Hey there, I’m wondering if anyone has done performance tuning on their GL-inet device running OpenVPN as a client.

I’ve just installed the latest stable firmware for my MV1000 Brume (version 3.212), but am seeing disappointing performance of 20-30Mbps to my VPN endpoint, (edit: further testing revealed higher speeds, see below) which is about 18ms away from me. I am connected via the WAN port via 100Mbps ethernet to a 300Mbps broadband connection.

Watching CPU usage on the Brume, I see that total CPU usage jumps to about 80% (of a total available 200%), with openvpn itself using 60% of a single core, while transferring data at about 25Mbps. This seems high for a device that claims to be capable of 97Mbps as an OpenVPN client.

I’m not familiar with tuning OpenVPN, and particularly not with the specifics of doing it on a GL and/or OpenWRT device - mainly just wondering if anybody has any pointers, tips & tricks, etc. My current plan is to figure out what ciphers are being used and alter them if it looks like the cipher has anything to do with the performance, it looks like the Mediatek CPU in the Brume has AES acceleration for instance.

2

In the OpenVPN .ovpn config file, is the cipher set to AES-128-CBC, AES-256-CBC, AES-128-GCM or AES-256-GCM?

Also, are you using VPN Policies, which may slow down the speed?

I do not work for and I do not have formal association with GL.iNet

3

No policies.

Cipher was originally AES-256-GCM, ran some tests and decided to try a cipher with better performance on the Brume. Unfortunately CHACHA20-POLY1305 isn’t available on the server, so I ended up trying AES-256-CBC.

The results were intriguing. The OpenVPN process uses less CPU than before, but performance is worse!

This may be because it’s also calling a message digest function to do part of the work that comes baked in to GCM mode?? My understanding of how the crypto works doesn’t really go that far.

In any event, this seems to indicate - along with the fact that OpenVPN isn’t maxing out a CPU core - that raw crypto performance on the Brume is not the bottleneck.

4

OpenSSL speed tests on Brume with firmware 3.212 (higher is better):

aes-128-gcm      22141.68k    29215.23k    31993.77k    33164.50k    33107.74k    33091.22k
aes-128-cbc      56278.58k   175647.17k   364216.70k   520701.93k   589960.53k   594046.92k
aes-256-gcm      21078.66k    28090.12k    30619.24k    31774.69k    31838.84k    31965.29k
aes-256-cbc      52943.55k   147465.71k   264592.75k   340154.53k   366811.28k   368562.25k
chacha20         31842.91k    68997.78k   142038.03k   159252.76k   167501.49k   167038.51k
chacha20-poly1305    23089.47k    50204.73k   102974.73k   119820.45k   127518.41k   127204.93k
1 Like
5

For what it’s worth, I get 55-65Mbps with client device connected via Ethernet cable to GL-MV1000W Brume running the OpenVPN client to a NordVPN server using AES-256-CBC.

I do not work for and I do not have formal association with GL.iNet

6

It is important to understand that OpenVPN is a protocol that requires a lot of resources. This means that an OpenVPN connection and then depending on the length of the keys (128, 160 or 256 bits) will lead to enormously different results. This is also true for Wireguiard, but not to the same extent for Weitewm. This means that a “Flint Router” can manage up to 35 MBit/s with OpenVPN with 256 bit key length, but with Wireguard it can manage 200MBit/s. We have created quite accurate lists in our test reports which also show this:
https://vpntester.org/router/tipp-vpn-am-heimrouter-verwenden/#vpn_router_vergleich

So it depends on the used VPN protocol. The degree of encryption, the distance to the VPN server and then especially the router used (model, processors, Ram, etc.) Larger routers are faster than smaller ones. See also the list.

1 Like
7

Cipher may not matter. Can you please check if you have enabled “real time data statistics” in the client page?

1 Like
8
  1. Cipher isn’t really that important I think.
  2. OpenVPN is single threaded and is limited to one core and wireguard is multithreaded so it can use several cores.
  3. Use UDP rather than TCP to avoid error checking.
  4. While it is counterintuitive, it is better to disable compression. Much traffic is compressed already, and compression is a security hazard. It also adds framing to the traffic, so you want to disable compression entirely, and not just none (none frames for compression and doesn’t use it; if you have a mismatch between client and server you will connect but no traffic will pass.)
1 Like
9

Can you please check if you have enabled “real time data statistics” in the client page?

I haven’t - learned a long time ago to keep that one turned off! :slight_smile:

Update

So, it seems I was hasty in drawing initial conclusions … in subsequent tests, I’ve seen up to about 80Mbps throughput, still using AES-256-CBC. I haven’t switched back to AES-256-GCM yet for more time comparing any difference in performance.

For anyone else reading, if you get the same real world performance out of either of those encryption methods, it’s probably better to use AES-256-GCM as it is considered somewhat more secure than AES-256-CBC.

I would love it if people who’ve done some OpenVPN tuning on GL-inet hardware would contribute tips here though - the Brume is the fastest GL-inet device I own, I have 2 or 3 other slower ones (Slate, GL-AR300, etc) and will eventually be trying to maximize OpenVPN performance on all of them.

Wireguard is definitely a lot faster for those who can use it, unfortunately for me, I am not ready to upgrade yet. So OpenVPN it is!

2 Likes
10

You could try running Smart Que Management if done correctly should decrease latency issues.
Trying different server locations.