After using openconnect to establish a VPN connection, I can't resolve host names for hosts in the new network, *unless* the "resolve" module is named on the "hosts" line in /etc/nsswitch.conf, which is not the default configuration in Fedora 29. This worked in Fedora 28 with the default configuration. In Fedora 28, the /etc/vpnc-script would modify the /etc/resolv.conf file with the DNS information for the VPN. In Fedora 29, it no longer takes that path. The vpnc-script looks in /etc/nsswitch.conf to see if "resolve" appears on the "hosts" line. If it doesn't, it tries to avoid depending on systemd-resolved. But if it sees the /sbin/resolvconf executable, it uses it. On Fedora 29, however, /sbin/resolvconf is a symbolic link to /bin/resolvectl, and resolvectl just talks to systemd-resolved, which vpnc-script doesn't appear to expect. So on systems where "resolve" doesn't appear on the "hosts" line of /etc/nsswitch.conf, name resolving still won't work. Since this seems to be the default configuration in Fedora 29, even on a freshly-installed system, that's not ideal. To make openconnect work for me on Fedora 29, I had to comment out the lines in vpnc-script that check for /sbin/resolvconf, and use the --script option of openconnect to point to my modified version of vpnc-script. It also works if I add "resolve [!UNAVAIL=return]" just before the "dns" entry on the "hosts" line in /etc/nsswitch.conf (now that https://bugzilla.redhat.com/show_bug.cgi?id=1644860 is fixed). Version-Release number of selected component (if applicable): vpnc-script-20171004-3.git6f87b0f.fc29.noarch How reproducible: It fails every time with the default /etc/nsswitch.conf file. Steps to Reproduce: Use openconnect to create a tunnel to a private network that has its own DNS servers. Try to resolve a host name using a command like "ping" that ultimately uses /etc/nsswitch.conf to control name resolution. Observe that names can't be resolved. Actual results: Host names can't be resolved. Expected results: Host names can be resolved. Additional info: none
Forwarded upstream: https://gitlab.com/openconnect/openconnect/issues/11
Maybe duplicate of bug 1646760.
*** Bug 1646760 has been marked as a duplicate of this bug. ***
There is indeed an issue on vpnc-script which makes it unusable in fedora. There are a little more info in the upstream tracker, though I have no time to follow up on that. If you send a pull request on vpnc-script which addresses the issue I will merge it.
If better someone else would like to take over this package, I'll be grateful.
I can do a pull request. Are you suggesting I file it against a Fedora repo (https://src.fedoraproject.org/rpms/vpnc-script.git?) or the upstream repo at http://git.infradead.org/users/dwmw2/vpnc-scripts.git/?
The fedora repo is best so we can try it there and if that works we can follow on upstream.
I submitted pull request https://src.fedoraproject.org/rpms/vpnc-script/pull-request/1 to change the script to accommodate the Fedora 29 arrangement.
vpnc-script-20171004-4.git6f87b0f.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-0e6c79cb84
Thank you! I've created builds for it.
vpnc-script-20171004-4.git6f87b0f.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-0e6c79cb84
vpnc-script-20171004-4.git6f87b0f.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
I've created bz#1713455 for a similar issue in openvpn.