OpenVPN 2.4 AES-NI speed
-
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.
