SOLVED: OVPN prompts almost every hour for pkcs11-PIN

[siegmarb]

Dear Users,

we're using with the openSC dll on windows 10/11 the cert-based authentication with a yubikey (PKCS11).
However openvpn prompts at around 55 minutes uptime for the yubikey-PIN. If PIN is not entered, vpn is after 1 hour uptime not routing traffic anymore, however openvpn log does not show any errors and shows still connected (green icon).

If the pin-prompt is canceled, opvn logs:

OpenSSL: error 0A080006:SSL_routines::EVP lib:
TLS_ERROR: BIO read_tls_read_plaintext_error

Server logs:

Dec 7 10:30:35 openvpn 30745 max/92.199.25.36:63666 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec 7 10:30:35 openvpn 30745 max/92.199.25.36:63666 TLS Error: TLS handshake failed
Dec 7 10:31:36 openvpn 30745 max/92.199.25.36:63666 [UNDEF] Inactivity timeout (--ping-restart), restarting
Dec 7 10:31:36 openvpn 53080 openvpn server 'ovpns4' user cert CN '' address '92.199.25.36:63666' - disconnected

OpenVPN-Client: 2.6.8 with OpenSSL 3.1.4)
OpenVPN-Server (PFSENSE, OpenSSL 3.0.12, OpenVPN 2.6.8 amd64-portbld-freebsd14.0)


UPDATE: looks like its the

--reneg-sec n
Renegotiate data channel key after n seconds (default=3600).When using dual-factor authentication, note that this default value may cause the end user to be challenged to reauthorize once per hour.

Also, keep in mind that this option can be used on both the client and server, and whichever uses the lower value will be the one to trigger the renegotiation. A common mistake is to set --reneg-sec to a higher value on either the client or server, while the other side of the connection is still using the default value of 3600 seconds, meaning that the renegotiation will still occur once per 3600 seconds. The solution is to increase --reneg-sec on both the client and server, or set it to 0 on one side of the connection (to disable), and to your chosen value on the other side.

[becm]

In theory, renegotiation should not really pose a problem.
We ran into this as well because the default PIN policy on slot 9c deviates (per operation instead of per session).
While this can be changed, not using the designated slots may restrict further hardware token use (e.g. blocking GPG slots).