Bug 1446623

It is hard to say exactly what is going wrong here.  My hunch is that you use CRL.  The CRL processing have been improved, and in my opinion doing the right thing now.  So if you have a CRL which is not valid, this is not an unexpected behaviour.  As stated in Changes.rst:


   "CRLs are now handled by the crypto library (OpenSSL or mbed TLS),
    instead of inside OpenVPN itself. The crypto library implementations
    are more strict than the OpenVPN implementation was. This might reject
    peer certificates that would previously be accepted. If this occurs,
    OpenVPN will log the crypto library's error description."
    https://github.com/OpenVPN/openvpn/blob/master/Changes.rst#version-241

There are a lot of bug fixes in OpenVPN v2.4 over v2.3, many of them can cause OpenVPN to reject connections or restarting.  In all these cases, that is due to configuration issues which OpenVPN earlier wrongfully ignored.

So even though it is regretful that an upgrade breaks.  But we cannot hold back an upgrade due to some users having misconfigured setups.  Especially not when it increases the overall security.  That OpenVPN used to allow (and most likely not properly handle) CRL files is not a good security feature.

Further, OpenVPN is not on the list of a critical package, which Firefox is.  So I don't see why OpenVPN should be treated like one when it is not on that list.
https://fedoraproject.org/wiki/Critical_path_package


If you can provide more details on why your setup broke (complete logs with --verb 4 + configuration files) I can reconsider to re-open this issue if it truly is an issue which should not have caused breakage.  But until that surfaces, I'm closing this as NOTABUG, as I believe this is entirely expected due to the enhanced CRL handling.

Not sure if it applies here, but our CRLs were simply expired and we had to
enlarge the range in our /etc/openvpn/openssl.cnf followed by openssl ca \
-gencrl -out /etc/openvpn/ovCA/crl/crl.pem -config /etc/openvpn/openssl.cnf

It looks like openvpn now expects config files in different locations.

For example < openvpn-2.4:
/etc/config/openvpn/server.conf
/etc/config/openvpn/client.conf

but for openvpn 2.4.x and up configs need to be in:
/etc/config/openvpn/server/server.conf
/etc/config/openvpn/client/client.conf

Maybe there should be a post install script for openvpn package moving existing config to new location?

(In reply to Valent Turkovic from comment #3)
> It looks like openvpn now expects config files in different locations.
> 
> For example < openvpn-2.4:
> /etc/config/openvpn/server.conf
> /etc/config/openvpn/client.conf
> 
> but for openvpn 2.4.x and up configs need to be in:
> /etc/config/openvpn/server/server.conf
> /etc/config/openvpn/client/client.conf

*IF* you choose to use the new systemd openvpn-{client,server}@.service unit files, then yes there are new locations.

You do not list the exact NVR of the openvpn version you have installed, so I presume you use openvpn-2.4.1-2.el7, which is the latest stable release:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-5c642f8063

That build does *also* provide openvpn@.service, which is using /etc/openvpn as before.

Users who used openvpn@.service should not notice any difference, but are *encouraged* to move towards the new unit files as they provide far better security and is based directly on the upstream openvpn projects' unit files - which is being shipped in lots of different systemd based distributions (so the behaviour should be much more similar across distributions).

Again, this is not a bug.  No, we will not move configuration files for users automatically.  They need to do that themselves - which is why we also provide the old unit file which should work as before.  The only change we have done to the old unit file is to slightly update it to make better use of OpenVPN 2.4's improved systemd integration.