OpenVPN 2.4 AES-NI speed
-
AES 256-GCM and SHA1 hash
SHA1 for the data channel is not used in this case, OpenVPN will ignore it because AES-GCM already includes hashing.
Side note:
Selecting a different –cipher, AES-CBC for instance, can lead to it being ignored if the client (2.4) supports a "better" cipher, AES-GCM.
This behaviour is called NCP (Negotiable Crypto Parameters) and if one specifically wants to have AES-CBC then one has to set
--ncp-disable in config.
See manual 2.4, start reading at "--auth alg" -
the settings are now different, I was just reporting what was in use at the time of the test.
For reference I now have it using aes 128-gcm as I consider aes 256 wasting resources, and sha256 for the reason you said, sha when used with gcm is only used for the control channel so the impact of strengthening it wont be noticeable.
I am pretty sure aes hardware offloading is working in my case regardless of the settings tho.
-
AES-NI is basically impossible to turn off in OpenSSL+OpenVPN. The old button in pfsense just confused a lot of people into turning on cryptodev, which used AES-NI in a different way and which was actually slower than the built-in mechanism that didn't need anything selected. So there may be a problem, but it's not because you can't shoot yourself in the foot with cryptodev.
How is it when in 2.3 With AES-NI module and cryptodev selected i can saturate my 300Mbps connection over VPN, but in 2.4 with a variance of modules loaded/unloaded/selected/unselected I lost nearly 75% of my throughput through the same link?
-
How is it when in 2.3 With AES-NI module and cryptodev selected i can saturate my 300Mbps connection over VPN, but in 2.4 with a variance of modules loaded/unloaded/selected/unselected I lost nearly 75% of my throughput through the same link?
I don't know, except that it's not because you lack AES-NI. A lot of things changed, and it's really hard to debug your box from here. I've never seen a system where aesni.ko + cryptodev was faster than not, so you could probably speed things up on 2.3 by turning it off. In 2.4 are you running 100% cpu? If not, that would suggest a networking bottleneck somewhere.
-
I don't know, except that it's not because you lack AES-NI. A lot of things changed, and it's really hard to debug your box from here. I've never seen a system where aesni.ko + cryptodev was faster than not, so you could probably speed things up on 2.3 by turning it off. In 2.4 are you running 100% cpu? If not, that would suggest a networking bottleneck somewhere.
In 2.3 turning off cryptodev reduces throughput.
Got dual E5-2670's with 4 cores provisioned (not that it matters for single-threaded), and CPU hits ~50% in 2.3, and when I tried 2.4 it didn't go over 10%, suggesting it wasn't working properly. -
CPU hits ~50% in 2.3, and when I tried 2.4 it didn't go over 10%, suggesting it wasn't working properly.
That pretty much confirms that it isn't an AESNI problem, or you'd be pegged at 100% of a core doing crypto operations. So it's mostly likely either network or openvpn config related.
-
CPU hits ~50% in 2.3, and when I tried 2.4 it didn't go over 10%, suggesting it wasn't working properly.
That pretty much confirms that it isn't an AESNI problem, or you'd be pegged at 100% of a core doing crypto operations. So it's mostly likely either network or openvpn config related.
Depends on how you're viewing CPU usage. In a dual core box, 50% could mean one core is 100% utilized in some utilities.
-
CPU hits ~50% in 2.3, and when I tried 2.4 it didn't go over 10%, suggesting it wasn't working properly.
That pretty much confirms that it isn't an AESNI problem, or you'd be pegged at 100% of a core doing crypto operations. So it's mostly likely either network or openvpn config related.
Depends on how you're viewing CPU usage. In a dual core box, 50% could mean one core is 100% utilized in some utilities.
Yeah, but 10% utilization might indicate a cpu-bottlenecked process on a 10 core system, not a 4 core system.
Rereading, this talk of "provisioning" suggest a VM is involved–possible regression in that area?
-
A little OT regarding AES-NI, but I just came across those and put them into the Custom Options box:
sndbuf 393216; rcvbuf 393216; push "sndbuf 393216"; push "rcvbuf 393216";Source:
http://winaero.com/blog/speed-up-openvpn-and-get-faster-speed-over-its-channel/Doubled my Windows OpenVPN Speed over the Internet. Now I'm close to the max. 200MBit that I normally only get when connecting directly via Ethernet to my WAN switch :)
-
Was curious if anyone else is still experiencing this? Testing openvpn with aes-256-gcm on 2.4.0.b.20170311.1958 my C2758 is pegging 1 cpu core and tapping out at ~150Mbit/s tops. Should drastic performance improvements be expected in the future or do i need to bite the bullet and upgrade to faster hardware to hit ~400Mbit/s? IPSEC isn't an option , i need policy based routing over the vpn.
-
Was curious if anyone else is still experiencing this? Testing openvpn with aes-256-gcm on 2.4.0.b.20170311.1958 my C2758 is pegging 1 cpu core and tapping out at ~150Mbit/s tops. Should drastic performance improvements be expected in the future or do i need to bite the bullet and upgrade to faster hardware to hit ~400Mbit/s? IPSEC isn't an option , i need policy based routing over the vpn.
That's about what you can expect out of a C2758. You can run multiple OpenVPN processes to scale across more cores, at the cost of configuration complexity.
-
On somewhat the same note - I found running pfsense in a hyper-v VM, negates having AES-NI, even though it shows up. Moved my router to a 7700K, and now my PIA VPN connection gets 100% of my speed. Without a VPN I get 340mb, with the VPN, I still get 340. Inside hyper-v, I was lucky to get 120mb.
I will never put Pfsense in a VM again I guess lol.
-
Was curious if anyone else is still experiencing this? Testing openvpn with aes-256-gcm on 2.4.0.b.20170311.1958 my C2758 is pegging 1 cpu core and tapping out at ~150Mbit/s tops. Should drastic performance improvements be expected in the future or do i need to bite the bullet and upgrade to faster hardware to hit ~400Mbit/s? IPSEC isn't an option , i need policy based routing over the vpn.
Try AES-128
I found running pfsense in a hyper-v VM, negates having AES-NI, even though it shows up. Moved my router to a 7700K, and now my PIA VPN connection gets 100% of my speed. Without a VPN I get 340mb, with the VPN, I still get 340. Inside hyper-v, I was lucky to get 120mb.
I will never put Pfsense in a VM again I guess lol.
There are plenty of people with working AES-NI in a VM.
And of course a 7700K maxes out 340Mbps VPN ::), so will a G3950. -
Was curious if anyone else is still experiencing this? Testing openvpn with aes-256-gcm on 2.4.0.b.20170311.1958 my C2758 is pegging 1 cpu core and tapping out at ~150Mbit/s tops. Should drastic performance improvements be expected in the future or do i need to bite the bullet and upgrade to faster hardware to hit ~400Mbit/s? IPSEC isn't an option , i need policy based routing over the vpn.
Try AES-128
I found running pfsense in a hyper-v VM, negates having AES-NI, even though it shows up. Moved my router to a 7700K, and now my PIA VPN connection gets 100% of my speed. Without a VPN I get 340mb, with the VPN, I still get 340. Inside hyper-v, I was lucky to get 120mb.
I will never put Pfsense in a VM again I guess lol.
There are plenty of people with working AES-NI in a VM.
And of course a 7700K maxes out 340Mbps VPN ::), so will a G3950.Don't buzz kill, Im excited haha :). Now if I could get this darn thing to reboot, id be in business! :). Only 2.4 supports the AES-NI right?
-
Only 2.4 supports the AES-NI right?
No.
OpenVPN uses OpenSSL for the crypto part.
Support for the AES-NI instruction set was included in OpenSSL 1.0.0. -
OpenVPN 2.4 adds support for the AES-GCM algorithm, which takes full advantage of the AES-NI hardware acceleration without also requiring the CPU to compute the hash for authentication. Up until OpenVPN 2.4, the only way to use that algorithm with pfSense was IPSEC, I believe. That lets you use your CPU for other functions rather than supporting the VPN connection. (yeah, technically it's all built into the processor, so it's really doing everything anyway, but AES-NI with AES-GCM doesn't affect CPU cycles available for other tasks).
-
@virgiliomi:
OpenVPN 2.4 adds support for the AES-GCM algorithm, which takes full advantage of the AES-NI hardware acceleration without also requiring the CPU to compute the hash for authentication. Up until OpenVPN 2.4, the only way to use that algorithm with pfSense was IPSEC, I believe. That lets you use your CPU for other functions rather than supporting the VPN connection. (yeah, technically it's all built into the processor, so it's really doing everything anyway, but AES-NI with AES-GCM doesn't affect CPU cycles available for other tasks).
This is mostly not true/confused. AES-GCM is a new cryptographic mode that combines encryption and authentication instead of using a separate algorithm for authentication. (As was historically the case with AES+SHA1 or AES+SHA256 or AES+UMAC, etc.) GCM is dramatically faster than AES-CBC+HMAC on amd/intel architecture CPUs, especially those with the carry-less multiplication operators (PCLMULQDQ, etc.), because it pipelines well. It is not the case that AES-GCM "uses the AES-NI more", it's that the algorithm is simply more efficient on current CPUs. (The catch is that it's either slower or impossible to implement on other kinds of cryptographic accelerators, so it's generally less efficient on older mobile devices or things like intel's quick assist.) AES-GCM doesn't affect CPU cycles for other tasks any differently than AES-CBC except insofar as it may require fewer cycles. (You may be confusing AES-NI with older architectures which used a distinct processor for crypto: in those, you could do other things with the main CPU while the coprocessor was doing crypto.) You generally won't see a dramatic speedup moving OpenVPN to AES-GCM because its architecture prevents the CPU from being able to really crunch on large blocks of data. It'll be a somewhat more efficient (and more secure) option, but it won't work miracles.
FWIW, the lastest intel/amd CPUs include SHA acceleration, so there's hardware acceleration for both encryption and authentication with AES-CBC-SHA1 just as there is with AES-GCM (using AES-NI+PCLMULQDQ). AES-GCM is still faster. The fact that there is a faster cipher mode doesn't make a different cipher mode less accelerated–AES-CBC with AES-NI is still tremendously faster than AES-CBC without AES-NI.
