2.4.2 - AESNI + Cryptodev + OpenVPN - canonical answer

[luckman212]

Sorry if this has been rehashed before but the answer (if it exists) could use clarification and seems scattered about in various places (pfSense Docs, r/PFSENSE, and dozens of threads here, some of which are pretty ancient).

With the recent push of redmine#7810 - on systems that have AES-NI support (e.g. Netgate appliances) what are the optimal settings for OpenVPN to keep CPU usage low and speeds high?

[perlenbacher]

I have one more option:

[jwt]

are you sure you're running 2.4.2?

https://redmine.pfsense.org/projects/pfsense/repository/revisions/f96376a378211155181a02a053cbb7ff9a700056/diff/src/usr/local/www/system_advanced_misc.php


[luckman212]

Yep I am on 2.4.2
I just didn't post a screenshot of that menu.
The picture I posted was from the ovpn client setup page.

[perlenbacher]

2.4.2-DEVELOPMENT (amd64)
built on Fri Oct 20 09:50:38 CDT 2017
FreeBSD 11.1-RELEASE-p2

[NineX]

to spmply test:
login to your box over ssh:

kldunload cryptodev
kldunload aesni
openssl speed -evp aes-256-cbc

note ouptput

then

kldload aesni
openssl speed -evp aes-256-cbc

note otput

then

kldunload aesni
kldload cryptodev

openssl speed -evp aes-256-cbc

note output

then

kldload aesni
openssl speed -evp aes-256-cbc

if you compare outputs from all tuns you will see which combination of modules works for you (note that openvpn utilise openssl)

in my case the faster aes operations i am getting when aesni and cryptodev are laoded.
https://www.freebsd.org/cgi/man.cgi?query=aesni&sektion=4
Says:

The aesni driver registers itself to accelerate AES operations for
    crypto(4). Besides speed, the advantage of using the aesni driver is
    that the AESNI operation is data-independent, thus eliminating some
    attack vectors based on measuring cache use and timings typically present
    in table-driven implementations.

to access crypto from userspace (openssl/openvpn)
you need crypto driver loaded
https://www.freebsd.org/cgi/man.cgi?query=cryptodev&sektion=4

The crypto driver gives user-mode applications access to hardware-accel-
    erated cryptographic transforms, as implemented by the crypto(9) in-ker-
    nel interface.

[NineX]

loading only aesni make sense when you wish to use ipsec only as ipsec tranforms are done in kernelspace.
otherwise keeping booth aesni + cryptodev is reasonable.

IMHO booth should be loaded by default cryptodev not cost tu much of memory at all.
only reason why those options are available is to make user allow unload those modules in case if there is incompatibility cpu vs module and/or bug in driver itself.

[belt9]

For an ovpn client choose no hardware crypto acceleration. It will choose the correct tool on its own.

Of.you have AES-NI then choose an AES algorithm. AES-128-GCM for most CPUs is best. Some CPUs (goldmont) have SHA acceleration, for those choose AES-128-CBC and SHA224.

Honestly the difference from SHA224 to 256 is completely negligible, but 224 isn't cracked so why do anything more, the same applies to AES.

Dont use SHA1.

No LZO compression would in theory be easiest on your CPU but I seriously doubt you'll tell any difference at all regardless of what you choose here.

[fraglord]

@belt9:

For an ovpn client choose no hardware crypto acceleration. It will choose the correct tool on its own.

Where you found this information?

[NineX]

@fraglord:

@belt9:

For an ovpn client choose no hardware crypto acceleration. It will choose the correct tool on its own.

Where you found this information?

In your CPU specification

[chrcoluk]

@belt9:

For an ovpn client choose no hardware crypto acceleration. It will choose the correct tool on its own.

Of.you have AES-NI then choose an AES algorithm. AES-128-GCM for most CPUs is best. Some CPUs (goldmont) have SHA acceleration, for those choose AES-128-CBC and SHA224.

Honestly the difference from SHA224 to 256 is completely negligible, but 224 isn't cracked so why do anything more, the same applies to AES.

Dont use SHA1.

No LZO compression would in theory be easiest on your CPU but I seriously doubt you'll tell any difference at all regardless of what you choose here.

great advice, I dont understand people preferring CBC over GCM and aes128-gcm is perfectly fine, no need for aes256.

[kejianshi]

GCM is not on every piece of client hardware out there.