Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: The openvpn update from 2.3 to 2.4 breaks my vpn server. After adjusting the configuration so that it works on 2.4.1, the update to 2.4.2 AGAIN breaks my server. What the heck is going on here? IMHO it is extremely bad taste to do these kinds of update within the same fedora release, it should have update compatibility. What I am seeing is that on 2.4.2 openvpn is running all configured instances and traffic is arriving, the handshake seems to be performed, but after that no traffic between the vpn client and the network hosted by the openvpn server. This is extremely annoying that these updates break my server all the time.
So *what* breaks? This is just a rant with no useful information to understand why it breaks. v2.4.1 to v2.4.2 does not contain anything else than bug and security fixes. No new behaviours. What you need to provide are: Logs (with --verb 4) and configuration files, preferably from both client and server.
> What I am seeing is that on 2.4.2 openvpn is running all configured instances > and traffic is arriving, the handshake seems to be performed, but after that > no traffic between the vpn client and the network hosted by the openvpn server.
nothing in the logs
WHAT?! Are you angry with me or something? I'm providing you with what I can! At the VERY least you could point out something like migration notes or something similar! Or ask me to provide more data, explaining what you actually want to see. This is absurd! Generally I'm reasonably satisfied with how bugs are handled but this is outrageous. Just let the user dangle with broken a vpn server because you updated a package with breaking changes.... WTH?
(In reply to Ferry Huberts from comment #4) > WHAT?! > > Are you angry with me or something? > I'm providing you with what I can! > At the VERY least you could point out something like migration notes or > something similar! Or ask me to provide more data, explaining what you > actually want to see. I already did. You provided nothing. >> What you need to provide are: Logs (with --verb 4) and configuration files, >> preferably from both client and server. Further, there are no changes between v2.4.1 and v2.4.2 which explains what you describe. ---------------------------------------------------------------- $ git shortlog v2.4.1..v2.4.2 David Sommerseth (6): auth-token: Ensure tokens are always wiped on de-auth docs: Fixed man-page warnings discoverd by rpmlint Make --cipher/--auth none more explicit on the risks plugin: Fix documentation typo for type_mask plugin: Export secure_memzero() to plug-ins Preparing v2.4.2 release Hristo Venev (1): Fix extract_x509_field_ssl for external objects, v2 Selva Nair (1): In auth-pam plugin clear the password after use Steffan Karger (10): cleanup: merge packet_id_alloc_outgoing() into packet_id_write() Don't run packet_id unit tests for --disable-crypto builds Fix Changes.rst layout Fix memory leak in x509_verify_cert_ku() mbedtls: correctly check return value in pkcs11_certificate_dn() Restore pre-NCP frame parameters for new sessions Always clear username/password from memory on error Document tls-crypt security considerations in man page Don't assert out on receiving too-large control packets (CVE-2017-7478) Drop packets instead of assert out if packet id rolls over (CVE-2017-7479) ValdikSS (1): Set a low interface metric for tap adapter when block-outside-dns is in use ---------------------------------------------------------------- In my 6 first patches, *none* of them should have any impact. Th patches from Hristo Venev, Selva Nair and ValdikSS should also not break in ways you describe. Steffans patches should also not break anything. We can ignore the mbed TLS patch, as Fedora 25 builds don't use that. The only plausible patch is the pre-NCP, which I do know work from my own environment. So please, provide logs and configurations. > This is absurd! No. What is absurd is to expect us to have a magic ball to understand what went wrong in your setup without even providing anything useful at all. "It doesn't work" is and will always be INSUFFICIENT_DATA. So: Provide log files with --verb 4 and configuration files.
I would rather not publish my config and logs here publicly. How to proceed?
I do see Thu May 18 12:31:58 2017 us=750018 xxxxxx VERIFY ERROR: depth=0, error=CRL has expired: ..... On openvpn 2.3 I do not have this problem at all. Do I now suddenly need to recreate the CRL? Once or on a schedule?
I created a key and revoked it, thereby creating a new CRL and now it works. This is quite unexpected. but it is fixed for me now. Let me just say that I completely missed your 'get me the logs with verb 4'. Doing that allowed me to fix it. I do want to say that this is very unexpected and should probably be documented somewhere
From the v2.4.0 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/v2.4.0/Changes.rst> That file is also packaged under /usr/share/doc/openvpn{,-2.4.?}/Changes.rst Previously, the CRL parser in OpenVPN did not consider the validity of the CRLs - it even didn't check that the CRL was issued by the same CA as the --ca certificate in use. So, this have been improved to actually ensure a valid CRL is used. Otherwise a valid CRL could be replaced by an invalid CRL and all revoked certificates in the valid CRL would suddenly have access again. You need to have a valid CRL at any time as of v2.4.0 and newer.
yes I did see that. It does _not_ mention that I might need to regenerate my crl. My CA was migrated to the server from a previous server. Does that invalidate the CRL? What are the scenarios unders which I need to regenerate the CRL?
You need to have a valid CRL. All CRLs have a validity time. $ openssl crl -noout -lastupdate -nextupdate -in ca.crl The time window a CRL is configurable. It is set by the CA tool generating your CRLs. This is the most important detail, as I expect you use the CRL from the CA also signing server and client certificates.
ok, so I'm still on easyrsa 2 and the default crl lifetime seems to be a month lastUpdate=May 18 10:40:00 2017 GMT nextUpdate=Jun 17 10:40:00 2017 GMT That is really short, and I now need to add a job to refresh the crl every month. Inconvenient. Anyway, thanks for the answers.
I am quite sure you can tweak easyrsa validity time through the openssl.cnf file. Look for default_crl_days.