23.09.01 Hardware Crypto showing No Hardware Crypto Acceleration for system with crypto chip installed

JonathanLee

I also see this id error in my 23.05.01 ssd on connects. I didn’t notice it until today

Pippin

I see no error in the logs posted above but that aside.....

The message

dco_update_peer_stat: invalid peer ID 0 returned by kernel

is not related to the issue described.
This can happen if userland has already forgotten a peer and kernel sends "post-disconnect stats" which seems to be the case

openvpn server 'ovpns1' user 'LeeFamilyVPN'address 'x.x.x.x' disconnected

right after the message.

stephenw10

Yup that's not an error that should ever prevent the service starting or cause connection issues etc.
Or has anything to do with hardware crypto support.

JonathanLee

@stephenw10 how can I prevent this issue?

stephenw10

You don't have to it's not an error that causes an problems.

petrt3522

I am seeing this same bug on 23.09.1 (I had to do a reinstall last week. This is a Lab/home license, install of 2.7 then upgrade to 23.09.1.) running on an HP thin client with AMD RX-427BB (x64) processor.
The Dashboard show AES + ChaCha Encryptions listed, but under OpenVPN server and clients it lists 'no hardware crypto acceleration' ?? I don't recall the processor usage before so I can not say what the difference is/is not.

stephenw10

That's not a bug. There can never be a crypto accelerator listed there because OpenSSL no longer accepts user mode engines in FreeBSD.

If you have a crypto device that is supported by the cryptodev framework then kernel mode operations will use that. So that's OpenVPN with DCO or IPSec.

keleticsaba

Just did a fresh re-install, what was planned a long ago.

My system:
CPU Type AMD GX-415GA SOC with Radeon(tm) HD Graphics
4 CPUs: 1 package(s) x 4 core(s)
AES-NI CPU Crypto: Yes (active)
QAT Crypto: No

Version 2.7.2-RELEASE (amd64)

The old - but up-to-dated - 2.7.2 install had AES-NI working, after clean install the openvpn can not set hw-crypto :(
(despite it is enabled/active)

dmesg | grep -i aes
Features2=0x3ed8220b<SSE3,PCLMULQDQ,MON,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AESNI,XSAVE,OSXSAVE,AVX,F16C>
Features2=0x3ed8220b<SSE3,PCLMULQDQ,MON,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AESNI,XSAVE,OSXSAVE,AVX,F16C>
aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS>

So, as i read the prev. replys it is the new normal, because by kernel it will be used?
But then why was it acting different (can-be selected) before the re-install?

stephenw10

The previous ability to set a hardware device in OpenVPN directly was a holdover from much older versions. It used to be that could set a hardware crypto engine for OpenSSL to use and that setting in OpenVPN passed that through. But that has not been possible for several FreeBSD versions now, that setting no longer did anything.
If your CPU is AES-NI capable OpenSSL will just use it directly without any additional setting.

Steve

JonathanLee

@stephenw10 the commands however in pfSense shell do not show use also in 23.09