[SOLVED] openresolv appending VPN's nameserver to resolv.conf
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
openresolv appending VPN's nameserver to resolv.conf
I recently switched my desktop netconfig to use straight DHCP (dhcpcd) rather than NetworkManager. However since making the switch, I've noticed that when I start up openvpn my vpn's nameserver is appended to my resolv.conf (via openresolv) rather replacing those entries as it used to. Exiting the openvpn process restores resolv.conf.bak to resolv.conf, showing that the "up" and "down" commands in my openvpn profile are being executed normally. I made no other change to my configuration.
I'm running Slackware 14.2 stable (with all updates applied as of this writing) including dhcpcd 6.8.2 and openvpn 2.4.6, and (from SBo): openresolv 3.9.0.
My dhcpcd.conf presently looks like this:
Code:
ipv4
dhcp
ipv6
dhcp6
controlgroup wheel
hostname
persistent
clientid
duid
option domain_name_servers, host_name
option classless_static_routes
#option ntp_servers
# Some interface drivers reset when changing the MTU so disabled by default.
option interface_mtu
require dhcp_server_identifier
slaac private
nohook lookup-hostname
nohook wpa_supplicant
My resolvconf.conf remains "stock":
Code:
resolv_conf=/etc/resolv.conf
Here is the config part of my openvpn profile (with key, cert, and vpn address omitted):
Code:
client
dev tun
remote <<address of vpn in some country>>
port 1194
verb 2
setenv UV_IPV6 yes
proto udp
push-peer-info
nobind
persist-key
persist-tun
auth-nocache
route-delay 5
resolv-retry infinite
explicit-exit-notify 5
cd /etc/openvpn
cipher AES-256-CBC
comp-lzo no
key-direction 1
remote-cert-tls server
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
What is it that I'm doing wrong that would cause resolv.conf to be no longer handled correctly by openresolv? I do not want to move back to NetworkManager to fix this (if it can be avoided).
Not sure if this will help, but I also use straight dhcpcd installation, and had a situation where connecting to a new ISP would would overwrite my resolv.conf (both the search domain and dns entries). I solved it by modifying /etc/dhclient.conf
Code:
supersede domain-search "somedomain.com";
supersede domain-name-servers 10.1.1.1;
request subnet-mask, broadcast-address, time-offset;
# Interface specific settings
interface "eth1" {
reject 10.1.1.0/24 ; # list of ips and ranges to reject
request routers; # obtains a default route
}
The "somedomain.com" is obviously another hostname, that I prefer to have in resolv.conf, rather than what the ISP provides. The "supersede domain-name-servers 192.168.1.1;" line is what I prefer to use as the dns server in resolv.conf.
The "reject 192.168.1.0/24" line is simply because I also run a dhcp server that I dont want to interfere, I'm sure you could do without it in your setup, and that you would need to change "eth1" to "tun" or similar. But overall this requests only the basics needed (default route), and keeps the resolv.conf how I like it.
I'm sure there is probably a better way to solve this in your situation, but I'll throw it out there just incase it helps.
EDIT: I just re-read what you wrote and realise I completely mis-understood. Perhaps check your dhclient.conf to see if there is a "prepend" (or "append") statement, which would cause dhcpcd to add values to resolv.conf instead of replace.
I am the maintainer of the openresolv SlackBuild script. What does your /etc/openvpn/update-resolv-conf contain? If you haven't modified it, you will need to, so openresolv knows what nameservers to use.
If this is already set, can you provide the output of your /etc/resolv.conf both before connecting to the VPN and after?
EDIT: I just re-read what you wrote and realise I completely mis-understood. Perhaps check your dhclient.conf to see if there is a "prepend" (or "append") statement, which would cause dhcpcd to add values to resolv.conf instead of replace.
Unless I'm misunderstanding something, dhclient.conf is used only by dhclient (when not handled by NetworkManager) so it shouldn't have any bearing on dhcpcd. In any case, dhclient.conf is presently empty so there are no append or prepend statements.
Quote:
Originally Posted by bassmadrigal
I am the maintainer of the openresolv SlackBuild script. What does your /etc/openvpn/update-resolv-conf contain? If you haven't modified it, you will need to, so openresolv knows what nameservers to use.
It's not modified (as I never needed to adjust it while still using NetworkManager). But looking at the file, it seems be a pretty standard script and the comments imply that you might want to push "dhcp-option" envs from one's openvpn profile but seem to give no indication that the file should be modified directly:
Code:
# Example envs set from openvpn:
# foreign_option_1='dhcp-option DNS 193.43.27.132'
# foreign_option_2='dhcp-option DNS 193.43.27.133'
# foreign_option_3='dhcp-option DOMAIN be.bnc.ch'
But the problem isn't that the vpn's nameserver isn't known, but rather that the vpn's nameserver is appended to the existing entries in resolv.conf when openvpn is started and then removed when openvpn is killed (leaving only the entries that existed before the vpn is started). The desired operation, of course, is that the existing entries should be moved to resolv.conf.bak and the vpn's nameserver should be the only entry in resolv.conf while openvpn is running.
Please excuse me if I'm being obtuse. What should I try doing next?
Somewhat by accident, I stumbled on a solution. In /etc/openvpn/update-resolv-conf, change line 48 from:
Code:
echo -n "$R" | /usr/sbin/resolvconf -a "${dev}.inet"
to
Code:
echo -n "$R" | /usr/sbin/resolvconf -x -a "${dev}.inet"
No other changes were needed. The vpn's nameserver now becomes the only entry in /etc/resolv.conf when openvpn is started and the prior entries are restored properly when the process is killed. This change is only needed when running dhcpcd standalone (i.e., DHCP netconfig with NetworkManager disabled), and no changes to update-resolv-conf are needed when you're running NetworkManager.
Does NM behave okay with that change in place? For the sake of clarity, would there be any adverse effects of adding the "-x" even if one were to use NM? I ask because it's perhaps worth mailing the openresolv maintainer to suggest patching that, but ONLY if it doesn't affect NM usage. Either way, it's probably worth a mail so that your findings can be documented in the SBo README for openresolv.
Somewhat by accident, I stumbled on a solution. In /etc/openvpn/update-resolv-conf, change line 48 from:
Code:
echo -n "$R" | /usr/sbin/resolvconf -a "${dev}.inet"
to
Code:
echo -n "$R" | /usr/sbin/resolvconf -x -a "${dev}.inet"
No other changes were needed. The vpn's nameserver now becomes the only entry in /etc/resolv.conf when openvpn is started and the prior entries are restored properly when the process is killed. This change is only needed when running dhcpcd standalone (i.e., DHCP netconfig with NetworkManager disabled), and no changes to update-resolv-conf are needed when you're running NetworkManager.
The update-resolv-conf script is not part of openresolv. It is a script that, from my understanding, originated on the Arch Wiki and then someone branched it out to its own github. It looks like they changed it back in 2016 to add the -x to the script, but the script in the SlackBuild is the original that was used when the openresolv SlackBuild was originally created (5 years before I took over). It "worked for me", so I never had to dig into it.
I'll get an update pushed soon. From the openresolv mailing list, it seems that a new release is pretty close and I'll try to push them together. Thanks for the info!
Last edited by bassmadrigal; 07-13-2019 at 01:07 PM.
From the openresolv mailing list, it seems that a new release is pretty close and I'll try to push them together. Thanks for the info!
Sorry for bumping an old thread, but the updated SBo for openresolv 3.9.2 does not include the proposed change to /etc/openvpn/update-resolv-conf. Could I also request this be added for the next update?
Sorry for bumping an old thread, but the updated SBo for openresolv 3.9.2 does not include the proposed change to /etc/openvpn/update-resolv-conf. Could I also request this be added for the next update?
Oops. I forgot about that part. There is now a 3.10.0 released. I'll try to get an update pushed this weekend (sadly, it might be after the public update, depending on when it is pushed -- I just have a work conference out of town this week and I won't be back until Friday evening).
Sorry for bumping an old thread, but the updated SBo for openresolv 3.9.2 does not include the proposed change to /etc/openvpn/update-resolv-conf. Could I also request this be added for the next update?
Update to 3.10.0 has been pushed to SBo and the changes to the update-resolv-conf script are included.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.