High CPU usage on OpenVPN with pc-engines Alix box

i use OpenVPN to provide VPN tunnel between a VPS server (OVH) on debian and my OpenWRT box (PC-Engines ALIX). My bandwidth is very slow when th VPN is on (15Mbit/s) against 50Mbit/s when it is off.
I notice the CPU usage is near 90% when the download test run. Alix is equipped with an AMD Geode LX800 CPU (500Mhz) and 256MB of RAM.

Previousy i used this hardware with Voyage/Linux distribution without any problem.

Do you think it is possible to improve the configuration and decrease the CPU usage ?

Thank you

It might not be the answer you're looking for, but the ALIX being an older system and encryption being rather demanding, you might want to look at Wireguard. WireGuard is very light on CPU usage, and OpenWrt keeps track of the recent versions pretty well.

Especially for a point to point tunnel WireGuard isn't too difficult to set up.


Depending on what you want to do, you could only route traffic to the Server if it is actually needed, reducing the load on the tunnel.

Thank you for your answer. I don't known WireGuard, i will have a look. I had performed another test. A copy/paste the config files of the openvpn client from the Alix to my desktop (Debian / Core i5@3.3Ghtz) and the problem is the same... My download is limited to 15Mbit/s. I think i have a problem with my openvpn config....
In the past I used ALIX to provide more than 10 openvpn tunnel without any problem, but it wasn't OpenWRT but Debian/voyage dedicated distribution.

Well, i use wireguard no. It is better but not very fast. The web page are charging faster than with openvpn, better latency i think. But my download rate is below 25Mbit/s with wireguard. Without, my download rate is above 60Mbit/s.
Wireguard have also a hight CPU usage.
Thank you very much for your help.

EDIT : my upload (30Mbit/s) is faster than my download, funny...
EDIT : perhaps a VPN using only AES-128 cypher could be relevant because Geode LX800 have a co-processor dedicated to crypt and decrypt AES-128 only. But Wireguard doesn't manage AES... I need to go back to OpenVPN :unamused:

@X-Raph-X, welcome to the community!

(I drafted this yesterday before others posted about Wireguard too.)

You need 1 Mhz of CPU (approximately) for each 1 Mbps of traffic. This is only counting plain bidirectional LAN-to-WAN speed with masquerade (not subsequent tunneling); and does not include things like: additional firewalling/logging/monitoring, DHCP, DNS, the Kernel itself, kmods, etc. also needing CPUs.

Now add the overhead of VPN encryption - and that's you you get.

I have 100/100 Internet connection...even with Wireguard, I get ~45/40 thru the tunnel. My difference...not much:

  • 833 MHz processor
  • crypto-offload engine in CPU :wink:
  • hardware RNG

You're getting 33% of line speed...I'm getting ~40%...and my processor was designed for it...so it may be worth testing a less intensive solution like Wireguard. Maybe also running your VPN on a dual-core or larger MHz processor.

Your speed seems normal, actually. It's consistent (and in the upper percentile) of performance I've seen from routers of similar processor speed.



Thank you very much for this detailed answer, it is very helpfull. I thought an Alix could manage more than 20Mbit/s of encrypted traffic, but it was a mistake.
Finally, i'm tired to tweak my connection, and i need it to work. So i decide to not use the VPN as default gateway, but only for the traffic redirected by my VPS. Later i will have a try with openvpn and full AES-128 cipher because i'm curious.

Thank you very much for the time.

1 Like

It is better without VPN ....


Another problem is that LTE connection are very changing, one time you can reach 60Mbit/s, a minute later you are restricted to 15Mbit/s

Of course it is.

You failed to mention this at first...very true.

Yes but my test was made in the same time with my mobile phone and my usb LTE modem huawei. The mobile phone was at least twice faster than the modem with the VPN.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.