Description of problem: The scripts included with the openvpn distribution: /usr/share/doc/openvpn/contrib/pull-resolv-conf/client.up /usr/share/doc/openvpn/contrib/pull-resolv-conf/client.down check for the resolvconf binary which they expect to be present, however as detailed in bz#1648108 the resolvconf name is now a link to resolvctl which doesn't do what these scripts expect Version-Release number of selected component (if applicable): I'm on Fedora 30 so I'm at openvpn-2.4.7-1.fc30.x86_64 but this seems to apply to fedora 29 also How reproducible: always Steps to Reproduce: 1.make openvpn config that uses client.up client.down to set DNS in resolv.conf 2.start vpn 3.examine resolv.conf Actual results: resolv.conf is not modified Expected results: resolv.conf should be modified Additional info: same issue as that described in bz#1648108 for which they are patching the script to more closely check the resolvconf script.
this is the workaround I'm applying for the moment -- /usr/share/doc/openvpn/contrib/pull-resolv-conf/client.up 2019-02-20 07:28:20.000000000 -0500 +++ ./client.up 2019-05-23 13:59:02.286015054 -0400 @@ -90,7 +91,7 @@ out="# resolv.conf autogenerated by ${0} (${dev})${nl}${dns}${ds}${domains}" # use resolvconf if it's available -if type resolvconf >/dev/null 2>&1; then +if [ "" ]; then #type resolvconf >/dev/null 2>&1; then printf "%s\n" "${out}" | resolvconf -p -a "${dev}" else # Preserve the existing resolv.conf --- /usr/share/doc/openvpn/contrib/pull-resolv-conf/client.down 2019-02-20 07:28:20.000000000 -0500 +++ ./client.down 2019-05-23 14:04:03.869443609 -0400 @@ -40,7 +40,7 @@ # been WARNED. PATH=/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbin -if type resolvconf >/dev/null 2>&1; then +if [ "" ]; then #type resolvconf >/dev/null 2>&1; then resolvconf -d "${dev}" -f elif [ -e /etc/resolv.conf.ovpnsave ] ; then # cp + rm rather than mv in case it's a symlink
The workaround here is kind of just forcing resolvconf. The client.{up,down} script isn't intended to be much more than somewhat functional scripts - more like examples (hence being located in /usr/share/doc). That said, having something more functional is not a bad thing. But, if you're using the command line approach - may I dare to point you at the new openvpn3-linux client? Packages can be found here: https://copr.fedorainfracloud.org/coprs/dsommers/openvpn3/ Basically all you need to do is: # dnf copr enable dsommers/openvpn3 # dnf install openvpn3-client Then any users can start OpenVPN tunnels, which also takes care of DNS configurations by default. For OpenVPN 2.x users, the openvpn2 command line interface is pretty much similar to what you're used to. $ openvpn2 --config CONFIG_FILE If the config contains 'daemon' or you pass '--daemon' on the command line, the tunnel runs in the background and need to be managed via 'openvpn3 session-manage'. Like: $ openvpn3 session-manage --config CONFIG_FILE --disconnect to stop and disconnect the VPN session.
(In reply to David Sommerseth from comment #2) > The workaround here is kind of just forcing resolvconf. it's forcing resolvconf to not be used because I changed the boolean to evaluate as false. The better fix is the one that looks like the patch in bz#1648108 which is here: https://src.fedoraproject.org/rpms/vpnc-script/pull-request/1#request_diff basically the boolean is also checking that resolvconf isn't a symlink to something totally different. The > client.{up,down} script isn't intended to be much more than somewhat > functional scripts - more like examples (hence being located in > /usr/share/doc). That said, having something more functional is not a bad > thing. I've been using those two scripts verbatim for years and IMO they should work correctly on the platform for which they are packaged, or they should be removed (which would make openvpn somewhat not useful). > > But, if you're using the command line approach - may I dare to point you at > the new openvpn3-linux client? Packages can be found here: > https://copr.fedorainfracloud.org/coprs/dsommers/openvpn3/ > > Basically all you need to do is: > > # dnf copr enable dsommers/openvpn3 > # dnf install openvpn3-client > > Then any users can start OpenVPN tunnels, which also takes care of DNS > configurations by default. For OpenVPN 2.x users, the openvpn2 command line > interface is pretty much similar to what you're used to. > > $ openvpn2 --config CONFIG_FILE > > If the config contains 'daemon' or you pass '--daemon' on the command line, > the tunnel runs in the background and need to be managed via 'openvpn3 > session-manage'. Like: > > $ openvpn3 session-manage --config CONFIG_FILE --disconnect > > to stop and disconnect the VPN session. Well I'm not on the bleeding edge for VPN software at the moment I just need my Red Hat VPN connection to work on my laptop for now, but this looks promising!
(In reply to Michael Bayer from comment #3) > (In reply to David Sommerseth from comment #2) > > The workaround here is kind of just forcing resolvconf. > > it's forcing resolvconf to not be used because I changed the boolean to > evaluate as false. Duh! Yeah, of course. Boolean logic confusion on my side. > The > > client.{up,down} script isn't intended to be much more than somewhat > > functional scripts - more like examples (hence being located in > > /usr/share/doc). That said, having something more functional is not a bad > > thing. > > > I've been using those two scripts verbatim for years and IMO they should > work correctly on the platform for which they are packaged, or they should > be removed (which would make openvpn somewhat not useful). Fair point. But these are upstream openvpn files, so I'll try to get that fixed upstream first - which propagates down to the Fedora packaging. > > But, if you're using the command line approach - may I dare to point you at > > the new openvpn3-linux client? Packages can be found here: > > https://copr.fedorainfracloud.org/coprs/dsommers/openvpn3/ > > > > Basically all you need to do is: > > > > # dnf copr enable dsommers/openvpn3 > > # dnf install openvpn3-client > > > > Then any users can start OpenVPN tunnels, which also takes care of DNS > > configurations by default. For OpenVPN 2.x users, the openvpn2 command line > > interface is pretty much similar to what you're used to. > > > > $ openvpn2 --config CONFIG_FILE > > > > If the config contains 'daemon' or you pass '--daemon' on the command line, > > the tunnel runs in the background and need to be managed via 'openvpn3 > > session-manage'. Like: > > > > $ openvpn3 session-manage --config CONFIG_FILE --disconnect > > > > to stop and disconnect the VPN session. > > Well I'm not on the bleeding edge for VPN software at the moment I just need > my Red Hat VPN connection to work on my laptop for now, but this looks > promising! I'm the one who has been working on that client for a couple of years already, and I'm only using this client nowadays. So, even though there is a "beta label" stuck to it, it is more that it hasn't been through any massive QE process yet. But it runs very stable and I'm even using it on some headless servers demanding 24/7 connectivity.
I'm sure it works great! It's just if I have to google for openvpn issues I get zillions of hits for the openvpn2 version at the moment. Unless I can bug you in perpetuity for every little problem I have :)
(In reply to Michael Bayer from comment #5) > I'm sure it works great! It's just if I have to google for openvpn issues > I get zillions of hits for the openvpn2 version at the moment. Yeah, hard to fight against a software package initially released in the early 2000 with millions of users. Probably need to get some help with some SEO gurus to get more visibility here. > Unless I can bug you in perpetuity for every little problem I have :) It's of course risky to promise support for perpetuity, but if it is in regards to real bugs and incorrect behaviours I certainly would love to hear about it :-) I do know there are people using this client in various settings and with various needs, and they mostly have been very quite until some odd things appeared - and then they go silent again after getting some help. So that either means it works really bad and they dropped using it - or that it works very well ;-) If you promise to read the documentation (lots of man pages packaged [0]) with a critical eye and report errors, bugs or share ideas for improvements, I'll be very flexible on helping you out - if not perpetuity, then at least something close enough. Btw. openvpn3-linux v6 beta got released on Friday. And this is probably the last thing I can say about the new client in this ticket; going off-topic for a bit now. [0] https://github.com/OpenVPN/openvpn3-linux/tree/master/docs/man/
The more I dive into this issue, the more confusing it gets. And these scripts should actually make use of systemd-resolved when available. Which is the case on Ubuntu 18.04 and newer ... so it makes me wonder why systemd-resolved is installed but not configured (or at least being used by NetworkManager). systemd-resolved isn't even being started on boot it seems. So far I've only done my research and testing on a F30 virtual machine provided by Digital Ocean. If systemd-resolved would be configured properly, the existing script should actually work out-of-the-box. It wouldn't modify /etc/resolv.conf, but `systemd-resolved --status` would list the proper DNS settings for that tun interface. And /run/systemd/resolve/resolv.conf would contain the setting as well. This begins to smell like a Fedora bug more than an OpenVPN bug.
*** Bug 1715664 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.