As a random aside: in a past life, I was helping somebody with a project where we needed a VPN connecting two locations. We were working with OpenVPN, and the nodes we had to handle the connection were beefy with large uplinks but we were hitting the single-core limitation so it didn't matter. We ended up building a proof of concept that launched one OpenVPN instance per core and then bonded them together, which let us get way closer to line rate.
Thankfully we never had to try them for real to see how horribly that would have gone under real load.
It’s surprising to me how bad the scaling is too. A 200megabits/s i what I was able to get on a fairly modern 10900k!
This with the default cipher? From what I can see, AES on a modern CPU should be orders of magnitude faster than that.
AES-ni is enabled and Linux confirms it’s enabled and openSSL has it enabled, but I found no easy way to check if it’s actually being used (I found a link long ago but lost it :( )
I was using either AES-256-GCM or AES-256-CBC.
It could also be default configs not set right. Brief google search tells me to tweak myriad of buffers and config options… Some saying without changing buffers they were limited to 100mbps for example. Lots said changing to udp/changing mtu/buffer/etc helped…
I agree with you that it should be fine/fast enough. That was my expectation too! However my testing in real life showed it not to be and it’s a common issue for openvpn. The easiest solution seems to be wire guard rather then tweaking random stuff with no idea what’s bottlenecks