This update has been unpushed.

There are coming reports on the CVE fixes impacting some configuration setups negatively.

https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg27342.html

This update has been unpushed.

There are coming reports on the CVE fixes impacting some configuration setups negatively. https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg27342.html

This update will be pulled until a 2.6.8 release is approaching.

There are coming reports on the CVE fixes impacting some configuration setups negatively. https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg27342.html

This update will be pulled until a 2.6.8 release is approaching.

There are issues with the xkey provider needed by Yubikeys and similar external PKI providers. Will spin a 2.6.1-2 build which contains an additional upstream patch.

This update has been unpushed.

As with the Fedora 36 build, I am requiring more +1 karmas to release this one due to the issues this release caused. If there are no -1 within 30 days, this is also considered stable.

An updated 2.5.7-2 build is now on the way into updates-testing. Please test this build and give the appropriate votes. Since this update caused so much issues and regressions, the 2.5.7-2 build requires more +1s than I normally require.

https://bodhi.fedoraproject.org/updates/FEDORA-2022-8ca0f56650

Upstream has sent a patch to the mailing list to be considered: https://patchwork.openvpn.net/patch/2504/

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 contains more related details as well: https://bugzilla.redhat.com/show_bug.cgi?id=2093069

@thm How do you start your client? Via the openvpn-client@.service systemd unit or NetworkManager?

Input and in the BZs here will be brought up with the upstream community as well

@dpsh This is the expected behaviour. With OpenVPN 2.5, the openvpn binary no longer executes ifconfig nor ip commands. It integrates directly using the Netlink interface, provided by the Linux kernel, to configure the tun/tap intefaces and routing.

Thanks for the glob pattern notifications; I see someone created #1953687, which I will follow up.

This update might fix #1432152 but it also depends on a fixed pkcs11-helper library as well. The change in OpenVPN alone is not enough. See this mail post for more details.

That is right. The tmpfiles.d stuff is related to systemd, which is EL7 and any Fedora releases after 17 or so. And /var/run/openvpn is packaged properly in openvpn-2.4.2 and openvpn-2.4.3, so this is no longer an issue. The openvpn-2.4.1 package this update is about, is obsolete and outdated.

Sorry, a little clarification. That bz comment you reference, is related to a Fedora release with systemd.

Please test a far newer OpenVPN release. This release is obsolete. OpenVPN 2.4.3 was put submitted 5 days ago.

$ rpm -ql openvpn | grep run
/var/run/openvpn
$ rpm -q openvpn
openvpn-2.4.3-1.el6.x86_64

This should not be an issue at all. You can find it here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-9ec615ff74

Btw. the bz you reference is also an invalid reference. That is related to Fedora 26, which relies on systemd and its tmpfiles service. That does not exist on EL6.

@fkooman, Fun fact: I got complaints that updates didn't restart the openvpn services.

Yes, it should restart all profiles on the server. It is not something we can change now; the cat is already out of the bag. So the next update will restart the service anyhow, also if we add some "tunable feature" in the next update - it will be restarted regardless.

But I can look at adding a "don't restart" feature. For example something like checking if a file named /etc/openvpn/server/.update-no-restart exists or not. I'm not saying that's how it will be, but that is one plausible solution.

So to the longer answer why this was changed. When I cleaned up the .spec file, a lot of moving parts had to be changed at the same time (otherwise we wouldn't be finished with the clean up until after the next 5-6 updates). A lot of the changes involved moving over to standardized RPM macros for doing a lot of things. So I chose to ensure we don't break running services needlessly on automated updates until the dust had settled a bit. And now it felt like the right time to do what most users expects.

Sorry, we have discovered some issues with the source tarball, so this needs to be rebuilt once upstream have fixed these issues.