Tonight, I was trying to launch my OpenVPN (for various reasons), but it didn't work, and the server spat this in my /var/log/openvpn_tcp.log:

AUTH-PAM: BACKGROUND: received command code: 0
AUTH-PAM: BACKGROUND: USER: jvoisin
AUTH-PAM: BACKGROUND: my_conv[0] query='Password: ' style=1
AUTH-PAM: BACKGROUND: user 'jvoisin' failed to authenticate: System error
PLUGIN_CALL: POST /usr/lib/x86_64-linux-gnu/openvpn/plugins/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=1
PLUGIN_CALL: plugin function PLUGIN_AUTH_USER_PASS_VERIFY failed with status 1: /usr/lib/x86_64-linux-gnu/openvpn/plugins/openvpn-plugin-auth-pam.so
TLS Auth Error: Auth Username/Password verification failed for peer

Something went wrong with pam (let alone the fact that Debian tought that it might be fun to move /usr/lib/openvpn/openvpn-plugin-auth-pam.so to /usr/lib/x86_64-linux-gnu/openvpn/plugins/openvpn-plugin-auth-pam.so without a warning a couple of weeks ago.), and I got this line in my /var/log/auth.log: PAM audit_log_acct_message() failed: Operation not permitted.

This is due to systemd's capabilities, that are wrongly set in the /lib/systemd/system/openvpn@.service file, missing the CAP_AUDIT_WRITE one, so edit it to look like something like this:

CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE CAP_AUDIT_WRITE 

Restart the systemd daemon with systemctl restart openvpn, and maybe issue a systemctl daemon-reload before, just in case (yes, I'm a completely legit systemd expert), and it should work again.

It took me way to long to find the culprit and to fix it, but I guess it's because I know nothing about capabilities, nor about this new fancy init system. Odds are that my next vpn endpoint will be something easier to manager, like alpine.