[u]Symptom[/u] I have an OpenVPN client running as a systemd daemon that works as expected in a chroot environment when the openvpn instance is run as root (both auth-token and the TLS handshake work upon key renegotiation). However, both auth-token and the TLS handshake fail (separately and together) when using the [b]user/group[/b] configuration settings to drop privileges. I do not believe the issue resides with the OpenVPN server or client configuration files themselves since the only change between a working client and a broken one resides in the removal of privileges (and thus have not posted those configuration files here). [u]Goal[/u] To run the client OpenVPN daemon with unprivileged user/group that succeeds at TLS renegotiation and using auth-token. [u]Notes: failed TLS handshake[/u] [list] [*]The initial handshake works without issue (likely as it occurs before dropping privileges as the client is required to pull auth-token and defers dropping privileges) [*]The renegotiation handshake proceeds through the point where (i) the server sends its public certificate and "hello done" (ii) the client checks the KU/EKU/x509 DN/CRL and (iii) the client writes its certificate and key exchange back to the server. [*]The failure occurs as a malloc failure in OpenSSL's BUF_MEM_grow_clean memory buffer routines (appears to be called from OpenSSL's ssl3_send_client_verify SSL routine) [*]For debugging purposes, I have set all of the Limit* systemd directives (AS,MEMLOCK,NPROC, etc) for the OpenVPN service to 'infinity' in an attempt to avoid an OOM scenario (running 'top' also indicates that virtual memory usage is under 70MB) [*]There are no apparent AVC SELinux denials[/list] [u]Notes: auth-token[/u] [list] [*]Not much to say here, except I've confirmed the server pushes the token to the client and that both the server and client register an AUTH_FAIL message[/list] [u]OS and application versions[/u] Fedora 25, 4.8.6-300.fc25,x86_64 OpenVPN 2.4.3 OpenSSL 1.0.2k-fips Thanks in advance for the help, and happy to provide any other pertinent information.I started digging through the OpenVPN/SSL codebase, but thought someone may have cracked this nut already.

Auth-token and TLS handshake failures on key renegotiation

ovpnusr

Symptom
I have an OpenVPN client running as a systemd daemon that works as expected in a chroot environment when the openvpn instance is run as root (both auth-token and the TLS handshake work upon key renegotiation). However, both auth-token and the TLS handshake fail (separately and together) when using the user/group configuration settings to drop privileges. I do not believe the issue resides with the OpenVPN server or client configuration files themselves since the only change between a working client and a broken one resides in the removal of privileges (and thus have not posted those configuration files here).

Goal
To run the client OpenVPN daemon with unprivileged user/group that succeeds at TLS renegotiation and using auth-token.

Notes: failed TLS handshake

The initial handshake works without issue (likely as it occurs before dropping privileges as the client is required to pull auth-token and defers dropping privileges)
The renegotiation handshake proceeds through the point where (i) the server sends its public certificate and "hello done" (ii) the client checks the KU/EKU/x509 DN/CRL and (iii) the client writes its certificate and key exchange back to the server.
The failure occurs as a malloc failure in OpenSSL's BUF_MEM_grow_clean memory buffer routines (appears to be called from OpenSSL's ssl3_send_client_verify SSL routine)
For debugging purposes, I have set all of the Limit* systemd directives (AS,MEMLOCK,NPROC, etc) for the OpenVPN service to 'infinity' in an attempt to avoid an OOM scenario (running 'top' also indicates that virtual memory usage is under 70MB)
There are no apparent AVC SELinux denials

Notes: auth-token

Not much to say here, except I've confirmed the server pushes the token to the client and that both the server and client register an AUTH_FAIL message

OS and application versions
Fedora 25, 4.8.6-300.fc25,x86_64
OpenVPN 2.4.3
OpenSSL 1.0.2k-fips

Thanks in advance for the help, and happy to provide any other pertinent information.I started digging through the OpenVPN/SSL codebase, but thought someone may have cracked this nut already.

TinCanTech

Both OpenVPN with systemd and OpenVPN with authentication tokens are still quite new.
There are some use cases that need to be investigated and this sounds like one of those ..

Can you please provide your sanitized configs and logs (@ verb 4) so we understand your
particular setup. Thanks.

Example can be found here: https://forums.openvpn.net/viewtopic.php?f=30&t=22603#p68963

dazo

First of all, issues like this would be better to report through the bug tracker (the same credentials as here on the forum). And this is a fairly good bug report too! Just missing what TinCanTech points out. That said ...

I doubt this is related to --auth-token. Codewise, that does not depend on privileged operations at all. I am more thinking that this is related to the systemd unit files. We've had some systemd unit files for quite some time, but there are a few variants of them unfortunately. Typically the openvpn@.service unit files was added by the distro package maintainers while the openvpn-{client,server}@.service unit files should be the ones we provide via the upstream OpenVPN. Now, you're lucky as I've been involved in the systemd work in OpenVPN and I am currently the main OpenVPN package maintainer in Fedora. So I do know that whichever of these unit files you use, are in a reasonable state - but there might be some corner cases we've not covered.

So we also need to know which unit files you use. I do highly recommend you to use the openvpn-client@.service unit file in your setup. The openvpn@.service unit file is deprecated and will be removed in F-27. The new unit files locks down OpenVPN even further in what it can do, so it is a more secure starting point for tunnels - and we plan on tightening this even further.

ovpnusr

Thank you both

@TinCanTech: I'm happy to provide (may take a day or so to get a chance to upload).

@dazo: I was debating where to post this (a poor late night decision on my part). I'll sign-up at the bug tracker and post the detail there (will inlcude a link from this thread to the bugtrac issue, unless folks would like me to post the same material here as well).

Also struck me as intuitively odd that auth-token would be affected -- my speculation (without an understanding of the code) is that the TLS handshake does not block ahead of PAM authentication, so the authentication plugin times out when the handshake fails.

I was simply using the old openvpn@.service (laziness from not looking in the directory), but can confirm the same behavior with the openvpn-client@.service (I only tweaked ExecStart to remove the --nobind parameter since my client has multiple NICs, and only want to bind to one -- specifying the bind in the config with the nobind threw a fatal error). Don't expect this would impact the symptom, but will also post the tweaked systemd service file, and the supplemental systemd conf files used for debugging, to the bugtrac.

BTW - nicely done on the systemd integration -- it took me awhile to get the CapabilityBoundingSet right on older implementations.

TinCanTech

Hi ovpnusr,

the users mailing list is the best place to start with such a high level problem.

Trac is the best place to report real bugs, once they have been flushed out on the mailing list above.

The forum is the best place to start for general help and has the best formatting tools (imho)
and if we find a something interesting here on the forum we escalate it with links back here.

You clearly know what you are doing and so moving to the ML or trac is a good idea in your case.
( I would advise you include configs and logs @ verb 4 )

Regards