23.09.01 Hardware Crypto showing No Hardware Crypto Acceleration for system with crypto chip installed
-
Yes, then boot so the safexcel module is not loaded. Then check the openvpn logs again. I expect that ID error to still be present.
-
@stephenw10 side note, can I do a boot environment and load 24 dev os or will that cause issues going back to 23.09?
-
Yes you can do that. There's no problem booting back to 23.09.1.
-
Yes this is as you expected. It still occurs with the hardware disabled.
-
Ok digging into that. I can only see one other reference to that kind of ID error.
Is that process an OpenVPN server?
How are the clients defined?
-
I also see this id error in my 23.05.01 ssd on connects. I didn’t notice it until today
-
I see no error in the logs posted above but that aside.....
The message
dco_update_peer_stat: invalid peer ID 0 returned by kernelis 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 caseopenvpn server 'ovpns1' user 'LeeFamilyVPN'address 'x.x.x.x' disconnectedright after the message.
-
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. -
@stephenw10 how can I prevent this issue?
-
You don't have to it's not an error that causes an problems.
-
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. -
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.
-
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: NoVersion 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? -
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
-
@stephenw10 the commands however in pfSense shell do not show use also in 23.09
