Since Ubuntu 18, why doesn't openvpn's client.ovpn:"dhcp-option DNS xxx.xxx.xxx.xxx" configure /etc/resolv.conf?
Solution 1
This is not a direct answer to the question (I don't know why /etc/resolv.conf is not properly updated -- but regardless of why, the real problem is that it isn't), but rather a solution to the underlying problem. After trying a LOT of things I read here and elsewhere, this is the only thing that finally worked for me:
in /etc/systemd/resolved.conf, change "yes" to "no" in this line (and uncomment if necessary) so that you end up with:
DNSStubListener=no
I believe what this does is tells the system not to look at /etc/resolv.conf (which in my case was directing it to 127.0.0.53 only -- it did not have the name servers OpenVPN was providing, as the original question mentions) for DNS. My guess is that being disallowed from relying upon /etc/resolv.conf forces it to fall back on the other (correct) DNS settings OpenVPN is providing.
Note that this will not work (at least it didn't for me) while dnsmasq is running, so if you have that installed, stop the service and set it not to run
Note that this assumes Ubuntu 18.04, and perhaps that other solutions mentioned here and elsewhere are already implemented, including having openvpn-systemd-resolved
and resolvconf
installed, and including the necessary lines in the .ovpn
file:
script security 2
up /etc/openvpn/update-systemd-resolved
up-restart
down /etc/openvpn/update-systemd-resolved
down-pre
Although I suspect that this fix renders that all irrelevant since it is getting DNS from somewhere besides /etc/resolv.conf, which I believe is what the update-systemd-resolved scripts are supposed to fix (but don't for some people).
Solution 2
Following: DNS set to systemd's 127.0.0.53 - how to change permanently?
If I install resolvconf:
$ sudo apt install resolvconf
$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
... so I guess 127.0.0.53
== whatever systemd-resolve --status
says.
There's no need to modify /etc/resolvconf/resolv.conf.d/tail
Related videos on Youtube
user48956
Updated on September 18, 2022Comments
-
user48956 over 1 year
I'm trying to setup an openvpn client with Ubuntu 18. I run these magic steps:
$ sudo apt-get install openvpn $ sudo apt-get install openvpn-systemd-resolved $ sudo openvpn --client --config ./client.ovpn Wed Jan 2 16:24:14 2019 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep 5 2018 Wed Jan 2 16:24:14 2019 library versions: OpenSSL 1.1.0g 2 Nov 2017, LZO 2.08 ... <14>Jan 2 15:58:07 update-systemd-resolved: Link 'tun0' coming up <14>Jan 2 15:58:07 update-systemd-resolved: Adding IPv4 DNS Server 172.17.0.1 <14>Jan 2 15:58:07 update-systemd-resolved: Setting DNS Domain mycompany.com <14>Jan 2 15:58:07 update-systemd-resolved: Adding IPv4 DNS Server 172.17.0.1 <14>Jan 2 15:58:07 update-systemd-resolved: Adding IPv4 DNS Server 8.8.8.8 <14>Jan 2 15:58:07 update-systemd-resolved: Setting DNS Domain mycompany.com <14>Jan 2 15:58:07 update-systemd-resolved: Setting DNS Domain mycompany.com <14>Jan 2 15:58:07 update-systemd-resolved: SetLinkDNS(4 3 2 4 172 17 0 1 2 4 172 17 0 1 2 4 8 8 8 8) <14>Jan 2 15:58:07 update-systemd-resolved: SetLinkDomains(4 1 mycompany.com false) Wed Jan 2 15:58:12 2019 ROUTE remote_host is NOT LOCAL Wed Jan 2 15:58:12 2019 /sbin/ip route add 96.78.182.190/32 via 172.20.10.1 Wed Jan 2 15:58:12 2019 /sbin/ip route add 8.8.8.8/32 metric 101 via 172.27.232.1 Wed Jan 2 15:58:12 2019 /sbin/ip route add 172.27.224.0/20 metric 101 via 172.27.232.1 Wed Jan 2 15:58:12 2019 /sbin/ip route add 172.17.0.0/16 metric 101 via 172.27.232.1 Wed Jan 2 15:58:12 2019 Initialization Sequence Completed
where:
$ tail ./client.ovpn # Recently downloaded from the openvpn server ... # Appended this magic .... # from here: https://askubuntu.com/questions/1032476/ubuntu-18-04-no-dns-resolution-when-connected-to-openvpn script-security 2 dhcp-option DNS 172.17.0.1 dhcp-option DOMAIN mycompany.com up /etc/openvpn/update-systemd-resolved down /etc/openvpn/update-systemd-resolved down-pre
And if I look at:
$ ls -la /etc/resolv.conf lrwxrwxrwx 1 root root 39 Nov 21 16:53 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf $ cat /etc/resolv.conf nameserver 127.0.0.53 <<< SHOULD BE 172.17.0.1 search mycompany.com
So it seems that the openvpn client didn't configure
/etc/resolv.conf
as happened with Ubuntu 14. Without this, if I "ping git" or "ping git.mycompany.com" to find our internal git service (or any internal service), I simply git the IP address of cable modem for all ping requests.If I edit /etc/resolv.conf and replace 127.0.0.53 with 172.17.0.1 as was requested in client.ovpn, then all works fine.
Why doesn't this client.ovpn cause /etc/resolv.conf to be updated in Ubuntu 18?
Curiously,
systemd-resolve
disagrees with/etc/resolv.conf
. What's up with that?$ systemd-resolve --status Global DNSSEC NTA: 10.in-addr.arpa 16.172.in-addr.arpa ... home internal intranet lan local private test Link 4 (tun0) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 172.17.0.1 8.8.8.8 DNS Domain: mycompany.com Link 2 (wlp2s0) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 172.20.10.1 fe80::1c71:e8cb:d5ec:89ef
For dig, at least, whatever
systemd-resolve --status
is reporting, is ignored:$ dig git ; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> git ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55917 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;git. IN A ;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) <<< Not the DNS I want ;; WHEN: Wed Jan 02 15:41:39 PST 2019 ;; MSG SIZE rcvd: 32
Related questions that didn't help:
-
Thomas Ward over 5 years
resolv.conf
is the old way of doing things,systemd-resolved
is now how the system handles DNS resolvers. Checksystemd-resolve --status
for "DNS Servers" entries to see whether it reflects the proper DNS servers in there or not. -
user48956 over 5 yearsIndeed:
systemd-resolve --status
showsLink3 (tun0) ... Servers: 172.17.0.1
and disagrees with/etc/resolv.conf
. Nevertheless, unless I edit/etc/resolv.conf
with the right magic DNS resolving is not happening at 172.17.0.1 For example if I run 'dig git', it tells my its still resolved by the server at127.0.0.53
-
user48956 over 5 yearsIs
systemd-resolve
compatible with theresolvconf
package? -
user48956 over 5 yearsIf I've understood freedesktop.org/software/systemd/man/…, glibc was changed to allow apps to use this new service. Is it possible that all my apps (dig, nslookup, chrome, etc...) are still using old glibc, and old /etc/resolv.conf?
-