Hi,
I've been involved with the OpenVPN community since 2009-ish, and has been working for OpenVPN Inc for a few years already as a developer on the core OpenVPN part - including the open source projects. I'm also responsible for the OpenVPN 3 Linux project.
Today I just checked one of the the NL configuration files, and I'm quite puzzled to see the comp-lzo being used (compression is disabled, but it adds compression framing - which impacts performance, even though just slightly). That was the least disappointing aspect. (we are working on a migration path to kick out the compression framing). OpenVPN is also working on getting rid of compression once and for all, due to the VORACLE attack vector.
The second aspect is the tun-mtu and tun-mtu-extra settings. Why? Also, we have noticed that b reducing the tun-mtu to somewhere between 1400 and 1440 also helps performance. As the OpenVPN wrapping of the wire packet sent to the remote side then typically goes below 1500 bytes - which most of the Internet infrastructure mostly tackles just fine. Otherwise, if the TUN packet itself is 1500 bytes, the OpenVPN wrapping increases the packet size enough so the packet often ends up being split into two packets - which impacts performance. Now mssfix is set to 1450, which is helping - but only for TCP packets, not UDP.
But the real ugly one is auth SHA512. I would actually expect Proton Technologies to have access to people understanding cryptology enough to tell them that will hit performance. First of all, this is used for HMAC authentication when a non GCM/AEAD cipher is used on the data channel. And with HMAC, even MD5 is considered secure enough. But the default SHA1 will give far better performance. If needing something more modern, going to SHA256 is reasonable - but SHA512 gives nothing extra on the security side, but will give you a slower connection.
The reason: SHA1 adds 20 bytes extra on the wire packet. SHA256 requires 32 bytes while SHA512 doubles that to 64 bytes. If your link MTU is 1500 bytes, SHA512 will occupy 4.3% of the packet payload, while SHA1 will only need 1.3%. Or to say it differently, using SHA1 instead of SHA512 will increase the data channel payload with 44 bytes (~2.9%). And given that there are no known weaknesses with HMAC-SHA1, you get more real data with the same security.
That said, the ProtonVPN server side does support NCP - so in most cases it will be upgraded to a GCM cipher if the client runs OpenVPN 2.4 or newer, or a OpenVPN 3 based client. The GCM tag will only require 8 bytes extra and the packet authentication is happening as part of the packet decryption - so there is a real performance advantage here.
Why am I bringing this up? A lot of things will change if you want to use the new Data Channel Offload feature which will arrive in OpenVPN 2.6 and already available as a tech-preview in OpenVPN 3 Linux. Fewer ciphers (only AES-GCM and ChaCha-Poly) are be supported and compression is unsupported (no plans to add support), to mention the most obvious ones. This will be yet another performance drop aspect.
So there is quite a mixed bag of issues, but all of them can result in poorer performance - which is bad both for OpenVPN and ProtonVPN. When more of these issues are ends up being used, the VPN performance will take a notiecable hit.
