Bug 2092800
| Summary: | After upgrade openvpn from 2.5.6-1.fc37 to 2.5.7-1.fc37 version NM cant connect to working network. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Mikhail <mikhail.v.gavrilov> |
| Component: | NetworkManager-openvpn | Assignee: | Lubomir Rintel <lkundrak> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | bgalvani, choeger, code, dazo, dcbw, dirk, francesco.giudici, hello, huzaifas, klember, lkundrak, luca.giuzzi, mhjacks, opensource, s.i.v.892, steve, tdawson, thaller, thomas.moschny, vbenes |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-06-12 02:05:18 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Mikhail
2022-06-02 09:34:37 UTC
I can confirm this. Version 2.5.7 does not work for me, but downgrading was again fine. NOTE: I just realize: I am on F36 (not Rawhide)!!! I also was able to reproduce the error "Cipher BF-CBC not supported" while using my Yubikey as a PKCS#11 token. As noted in openVPN release notes https://github.com/OpenVPN/openvpn/blob/release/2.5/Changes.rst#new-features I added "providers legacy default" to my configuration and was able to start the vpn. Not sure yet why that's required yet. @Anthony Rabbito "I added "providers legacy default" to my configuration" How did you do it? "providers legacy default" are required to re-enable deprecated and legacy cipher algorithms in OpenSSL 3.0. Prior openvpn-2.5 releases used the older OpenSSL 1.1 API while v2.5.7 have backported a few OpenSSL 3 API compatibility patches. Now, these issues appears because your configuration files, private keys or certificates are using deprecated or really legacy crypto algorithms. Many of them (like BF-CBC, SHA1, RSA keys shorter than 2048 bits, to mention a few) are really NOT recommended to use. OpenSSL 3 by default disables a lot of them. Do consider the "providers legacy default" approach to be a temporarily workaround until you get your configurations, key files and certificates upgraded to a more reasonable security level. (In reply to dirk from comment #3) > @Anthony Rabbito > > "I added "providers legacy default" to my configuration" > > How did you do it? I suspect a plain-text configuration file was used instead of NetworkManager-openvpn. And to be honest, I don't think NetworkManager-openvpn should support the --providers option for the time being. Yes, there will be some turmoil due to the new requirements in OpenSSL 3. But solving the real issues (weak setups) is by far better than working around them through some options. > I suspect a plain-text configuration file was used instead of NetworkManager-openvpn.
The ovpn file was provided to me by my employer. Re-importing the ovpn file with the new openvpn package did not help to solve this issue.
> I suspect a plain-text configuration file was used instead of NetworkManager-openvpn. And to be honest, I don't think >NetworkManager-openvpn should support the --providers option for the time being. Yes this is a plain-text configuration as I cannot use NetworkManager with a pkcs11 token. See here https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/issues/78 for more info This problem is now also present in F36 (this could be considered a violation of the stable releases updates policy).
As nm-openvpn doesn't seem to support the `--providers` option, I used a brute-force workaround:
$ mv /usr/sbin/openvpn{,.orig}
$ echo -e '#!/bin/sh\nexec openvpn.orig --providers legacy default "$@"' > /usr/sbin/openvpn
$ chmod +x /usr/sbin/openvpn
$ /sbin/restorecon -v /usr/sbin/openvpn.orig /usr/sbin/openvpn
Note: This is a hack, and it will also not survive the next RPM update. Use at your own risk!
Upstream has sent a patch to the mailing list to be considered: I've put together a few quick test builds F36: https://koji.fedoraproject.org/koji/taskinfo?taskID=87830798 Rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=87830820 If some of you can do a quick test of those build to see if that helps, I can get a 2.5.7-2 prepared later this weekend. Upstream patch: https://patchwork.openvpn.net/patch/2504/ Thanks for the update! I have tested the koji builds, and they work well on the client side. I have two Fedora 36 openvpn clients and am also running the server on Fedora 36; I still had to add "providers legacy default" line to my server config to allow it to start, even with the new Koji builds. (I did not have to modify the client configs with the new Koji builds.) This might be considered a separate issue from the one described in the bug title, but it seems they might stem from the same cause. I confirm that the koji builds fix the problem of connecting with an external vpn (not under my control) for me as well. (In reply to David Sommerseth from comment #9) > Upstream has sent a patch to the mailing list to be considered: > > I've put together a few quick test builds > > F36: https://koji.fedoraproject.org/koji/taskinfo?taskID=87830798 > Rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=87830820 > > If some of you can do a quick test of those build to see if that helps, I > can get a 2.5.7-2 prepared later this weekend. This works for me too in NetworkManager CI tests where I use a straightforward server config under c9s. https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/blob/main/nmci/ctx.py#L690 Could you please push the new version to EPEL as well? Thank you so much! Vladimir FEDORA-2022-8ca0f56650 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-8ca0f56650 The update I've pushed out via Fedora Bodhi now (FEDORA-2022-8ca0f56650) carries an updated upstream patch for better handling deprecated and unavailable ciphers. This patch is now included officially for a coming OpenVPN 2.5.8 release coming later. In addition this update also removes BF-CBC from the --data-ciphers list in the openvpn-server@.service unit file. The change to the unit file will result in OpenVPN server running on Fedora 36 and newer will no longer support BF-CBC out-of-the-box. This will now require an explicit configuration change to re-enable this. I concluded this was the best approach, since OpenSSL 3.0 by default does no longer support this cipher without re-enabling legacy ciphers. Please test this update and give the update positive karma on successful testing. Since the 2.5.7-1 release caused so much issues, I decided to require more +1s to label it as stable. (In reply to Vladimir Benes from comment #13) [...snip...] > > Could you please push the new version to EPEL as well? Thank you so much! I presume you mean EPEL-9. I can do that once I am certain the updated F36 build headed for updates-testing works as expected. FEDORA-2022-8ca0f56650 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-8ca0f56650` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-8ca0f56650 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2022-8ca0f56650 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-EPEL-2022-dd161a4d75 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-dd161a4d75 @vbenes : I have pushed out an EPEL-9 build via Fedora Updates now. Please test. FEDORA-EPEL-2022-dd161a4d75 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-dd161a4d75 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. (In reply to Fedora Update System from comment #17) > FEDORA-2022-8ca0f56650 has been pushed to the Fedora 36 testing repository. > Soon you'll be able to install the update with the following command: > `sudo dnf upgrade --enablerepo=updates-testing > --advisory=FEDORA-2022-8ca0f56650` > You can provide feedback for this update here: > https://bodhi.fedoraproject.org/updates/FEDORA-2022-8ca0f56650 > > See also https://fedoraproject.org/wiki/QA:Updates_Testing for more > information on how to test updates. This issue still not fixed in Rawhide. (In reply to Mikhail from comment #22) [...snip...] > > This issue still not fixed in Rawhide. Sorry about that! I've kicked off a rawhide build as well. https://koji.fedoraproject.org/koji/taskinfo?taskID=89074902 FEDORA-EPEL-2022-dd161a4d75 has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report. |