update-systemd-resolved icon indicating copy to clipboard operation
update-systemd-resolved copied to clipboard

Published 20 hours ago • verified publisher icon jonathanio

update-systemd-resolved failing to update DNS settings in Ubuntu 18.04

Open cwray opened this issue 6 years ago • 17 comments

This script was working a few days ago for me. Had to rebuild my laptop and now it is not working. Currently running ubuntu 18.04

It looks like it sets the DNS servers from the output. But actually does not add them.

Mon Mar 11 14:56:34 2019 /etc/openvpn/scripts/update-systemd-resolved tun0 1500 1572 172.30.0.6 172.30.0.5 init <14>Mar 11 14:56:34 update-systemd-resolved: Link 'tun0' coming up <14>Mar 11 14:56:34 update-systemd-resolved: Adding IPv4 DNS Server 10.248.16.1 <14>Mar 11 14:56:34 update-systemd-resolved: Adding IPv4 DNS Server 10.248.240.1 <14>Mar 11 14:56:34 update-systemd-resolved: Setting DNS Domain example.com <14>Mar 11 14:56:34 update-systemd-resolved: SetLinkDNS(8 2 2 4 10 248 16 1 2 4 10 248 240 1) <14>Mar 11 14:56:34 update-systemd-resolved: SetLinkDomains(8 1 example.com false) Mon Mar 11 14:56:34 2019 /sbin/ip route add 10.248.240.0/20 via 172.30.0.5 Mon Mar 11 14:56:34 2019 /sbin/ip route add 10.248.32.0/20 via 172.30.0.5 Mon Mar 11 14:56:34 2019 /sbin/ip route add 10.248.16.0/20 via 172.30.0.5 Mon Mar 11 14:56:34 2019 /sbin/ip route add 10.248.0.0/20 via 172.30.0.5 Mon Mar 11 14:56:34 2019 /sbin/ip route add 172.30.0.1/32 via 172.30.0.5

===============================================================================
                             Device details (tun0)
===============================================================================
GENERAL.DEVICE:                         tun0
-------------------------------------------------------------------------------
GENERAL.TYPE:                           tun
-------------------------------------------------------------------------------
GENERAL.HWADDR:                         
-------------------------------------------------------------------------------
GENERAL.MTU:                            1500
-------------------------------------------------------------------------------
GENERAL.STATE:                          100 (connected)
-------------------------------------------------------------------------------
GENERAL.CONNECTION:                     tun0
-------------------------------------------------------------------------------
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/ActiveConnection/8
-------------------------------------------------------------------------------
IP4.ADDRESS[1]:                         172.30.0.6/32
IP4.GATEWAY:                            
IP4.ROUTE[1]:                           dst = 10.248.32.0/20, nh = 172.30.0.5, mt = 0
IP4.ROUTE[2]:                           dst = 10.248.0.0/20, nh = 172.30.0.5, mt = 0
IP4.ROUTE[3]:                           dst = 172.30.0.1/32, nh = 172.30.0.5, mt = 0
IP4.ROUTE[4]:                           dst = 10.248.240.0/20, nh = 172.30.0.5, mt = 0
IP4.ROUTE[5]:                           dst = 10.248.16.0/20, nh = 172.30.0.5, mt = 0
-------------------------------------------------------------------------------
IP6.ADDRESS[1]:                         fe80::6d14:7405:78e6:5d4f/64
IP6.GATEWAY:                            
-------------------------------------------------------------------------------

cwray avatar Mar 11 '19 21:03 cwray

Routes get added. Search domain and DNS don't.

cwray avatar Mar 11 '19 21:03 cwray

Same here on Ubuntu 18.40 - 64 bit Script is correctly modify /run/systemd/resolve/resolv.conf but not /run/systemd/resolve/stub-resolv.conf And /etc/resolv.conf is a ling to /run/systemd/resolve/stub-resolv.conf

Regards Franco Spinelli

frspin avatar Mar 30 '19 13:03 frspin

I'm having the same problem on Ubuntu 18.04. The logs show that the script is running, but the nameserver and search domain don't get updated.

Has anyone found the cause or a solution?

adamshand avatar Apr 30 '19 01:04 adamshand

@cwray, @frspin, and @adamshand,

What is the output of your systemd-resolve --status? Also, what are the contents of your nssswitch.conf file and resolv.conf file?

If the DNS queries are not working then that suggests either they're not getting added to systemd-resolved via the script (although the script itself isn't failing, so I'm not certain on this) or your DNS queries are not being directed to systemd-resolved either using NSS or via the stub resolver. These three files will help diagnose this.

jonathanio avatar May 19 '19 18:05 jonathanio

Same issue here, just after updating Ubuntu. Maybe some new package broke the script?

systemd-resolve --status for me reports:

Link 17 (tun0)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

So there seems to be somethin wrong...

[edit] Attaching syslog:

May 20 17:28:12 MYLAPTOP NetworkManager[1192]: <info>  [1558366092.0624] audit: op="connection-activate" uuid="615d0535-8c7b-4413-a682-f60417a59755" name="MyVPN" pid=2268 uid=1000 result="success"
May 20 17:28:12 MYLAPTOP gnome-shell[1392]: JS ERROR: TypeError: item is undefined#012setActiveConnections/<@resource:///org/gnome/shell/ui/status/network.js:1520:17#012setActiveConnections@resource:///org/gnome/shell/ui/status/network.js:1517:9#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22#012_syncVpnConnections@resource:///org/gnome/shell/ui/status/network.js:1855:9#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
May 20 17:28:12 MYLAPTOP NetworkManager[1192]: <info>  [1558366092.0704] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",0]: Started the VPN service, PID 24468
May 20 17:28:12 MYLAPTOP NetworkManager[1192]: <info>  [1558366092.0769] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",0]: Saw the service appear; activating connection
May 20 17:28:12 MYLAPTOP NetworkManager[1192]: <info>  [1558366092.1422] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",0]: VPN plugin: state changed: starting (3)
May 20 17:28:12 MYLAPTOP NetworkManager[1192]: <info>  [1558366092.1423] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",0]: VPN connection: (ConnectInteractive) reply received
May 20 17:28:12 MYLAPTOP nm-openvpn[24474]: WARNING: file '/home/alai/VPN/fw-udp-1199-vpn-alai.p12' is group or others accessible
May 20 17:28:12 MYLAPTOP nm-openvpn[24474]: WARNING: file '/home/alai/VPN/./fw-udp-1199-vpn-alai-tls.key' is group or others accessible
May 20 17:28:12 MYLAPTOP nm-openvpn[24474]: OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep  5 2018
May 20 17:28:12 MYLAPTOP nm-openvpn[24474]: library versions: OpenSSL 1.1.0g  2 Nov 2017, LZO 2.08
May 20 17:28:12 MYLAPTOP nm-openvpn[24474]: WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.
May 20 17:28:12 MYLAPTOP nm-openvpn[24474]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
May 20 17:28:12 MYLAPTOP nm-openvpn[24474]: TCP/UDP: Preserving recently used remote address: [AF_INET]87.241.35.198:1199
May 20 17:28:12 MYLAPTOP nm-openvpn[24474]: UDP link local: (not bound)
May 20 17:28:12 MYLAPTOP nm-openvpn[24474]: UDP link remote: [AF_INET]87.241.35.198:1199
May 20 17:28:12 MYLAPTOP nm-openvpn[24474]: NOTE: chroot will be delayed because of --client, --pull, or --up-delay
May 20 17:28:12 MYLAPTOP nm-openvpn[24474]: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
May 20 17:28:12 MYLAPTOP nm-openvpn[24474]: [My Office VPN] Peer Connection Initiated with [AF_INET]87.241.35.198:1199
May 20 17:28:13 MYLAPTOP nm-openvpn[24474]: TUN/TAP device tun1 opened
May 20 17:28:13 MYLAPTOP nm-openvpn[24474]: /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper --debug 0 24468 --bus-name org.freedesktop.NetworkManager.openvpn.Connection_24 --tun -- tun1 1500 1553 172.31.252.244 255.255.255.0 init
May 20 17:28:13 MYLAPTOP systemd-udevd[24490]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6068] manager: (tun1): new Tun device (/org/freedesktop/NetworkManager/Devices/21)
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6132] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",0]: VPN connection: (IP Config Get) reply received.
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6143] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",21:(tun1)]: VPN connection: (IP4 Config Get) reply received
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6151] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",21:(tun1)]: Data: VPN Gateway: 87.241.35.198
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6151] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",21:(tun1)]: Data: Tunnel Device: "tun1"
May 20 17:28:13 MYLAPTOP nm-openvpn[24474]: chroot to '/var/lib/openvpn/chroot' and cd to '/' succeeded
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6152] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",21:(tun1)]: Data: IPv4 configuration:
May 20 17:28:13 MYLAPTOP nm-openvpn[24474]: GID set to nm-openvpn
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6152] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",21:(tun1)]: Data:   Internal Gateway: 172.31.252.1
May 20 17:28:13 MYLAPTOP nm-openvpn[24474]: UID set to nm-openvpn
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6152] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",21:(tun1)]: Data:   Internal Address: 172.31.252.244
May 20 17:28:13 MYLAPTOP nm-openvpn[24474]: Initialization Sequence Completed
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6152] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",21:(tun1)]: Data:   Internal Prefix: 24
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6152] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",21:(tun1)]: Data:   Internal Point-to-Point Address: 172.31.252.244
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6152] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",21:(tun1)]: Data:   Static Route: 172.27.0.0/24   Next Hop: 172.31.252.1
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6152] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",21:(tun1)]: Data:   Static Route: 172.27.240.0/20   Next Hop: 172.31.252.1
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6152] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",21:(tun1)]: Data:   Static Route: 192.168.222.0/24   Next Hop: 172.31.252.1
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6152] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",21:(tun1)]: Data:   Static Route: 185.48.32.186/32   Next Hop: 172.31.252.1
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6152] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",21:(tun1)]: Data:   Static Route: 80.247.66.0/24   Next Hop: 172.31.252.1
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6153] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",21:(tun1)]: Data:   Static Route: 87.248.32.84/32   Next Hop: 172.31.252.1
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6153] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",21:(tun1)]: Data:   Static Route: 178.239.180.149/32   Next Hop: 172.31.252.1
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6153] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",21:(tun1)]: Data:   Static Route: 80.247.66.96/32   Next Hop: 172.31.252.1
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6153] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",21:(tun1)]: Data:   Static Route: 87.248.32.223/32   Next Hop: 172.31.252.1
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6153] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",21:(tun1)]: Data:   Static Route: 172.31.252.0/24   Next Hop: 0.0.0.0
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6153] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",21:(tun1)]: Data:   Internal DNS: 172.27.0.42
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6153] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",21:(tun1)]: Data:   Internal DNS: 172.27.0.33
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6153] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",21:(tun1)]: Data:   DNS Domain: '(none)'
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6154] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",21:(tun1)]: Data: No IPv6 configuration
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6171] devices added (path: /sys/devices/virtual/net/tun1, iface: tun1)
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6172] device added (path: /sys/devices/virtual/net/tun1, iface: tun1): no ifupdown configuration found.
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6172] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",21:(tun1)]: VPN plugin: state changed: started (4)
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6214] vpn-connection[0x55bf119fe790,615d0535-8c7b-4413-a682-f60417a59755,"MyVPN",21:(tun1)]: VPN connection: (IP Config Get) complete
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6217] device (tun1): state change: unmanaged -> unavailable (reason 'connection-assumed', sys-iface-state: 'external')
May 20 17:28:13 MYLAPTOP systemd[1]: Starting resolvconf-pull-resolved.service...
May 20 17:28:13 MYLAPTOP nm-dispatcher: req:3 'vpn-up' [tun1]: new request (1 scripts)
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6360] keyfile: add connection in-memory (2e160376-141a-4eb4-a93d-f38c08f33ccf,"tun1")
May 20 17:28:13 MYLAPTOP nm-dispatcher: req:3 'vpn-up' [tun1]: start running ordered scripts...
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6374] device (tun1): state change: unavailable -> disconnected (reason 'connection-assumed', sys-iface-state: 'external')
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6386] device (tun1): Activation: starting connection 'tun1' (2e160376-141a-4eb4-a93d-f38c08f33ccf)
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6395] device (tun1): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'external')
May 20 17:28:13 MYLAPTOP systemd[1]: Started resolvconf-pull-resolved.service.
May 20 17:28:13 MYLAPTOP gnome-shell[1392]: JS ERROR: TypeError: item is undefined#012setActiveConnections/<@resource:///org/gnome/shell/ui/status/network.js:1520:17#012setActiveConnections@resource:///org/gnome/shell/ui/status/network.js:1517:9#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22#012_syncVpnConnections@resource:///org/gnome/shell/ui/status/network.js:1855:9#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6535] device (tun1): state change: prepare -> config (reason 'none', sys-iface-state: 'external')
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6539] device (tun1): state change: config -> ip-config (reason 'none', sys-iface-state: 'external')
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6540] device (tun1): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'external')
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6544] device (tun1): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'external')
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6546] device (tun1): state change: secondaries -> activated (reason 'none', sys-iface-state: 'external')
May 20 17:28:13 MYLAPTOP NetworkManager[1192]: <info>  [1558366093.6604] device (tun1): Activation: successful, device activated.
May 20 17:28:13 MYLAPTOP nm-dispatcher: req:4 'up' [tun1]: new request (1 scripts)
May 20 17:28:13 MYLAPTOP systemd-resolved[1007]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
May 20 17:28:13 MYLAPTOP nm-dispatcher: req:4 'up' [tun1]: start running ordered scripts...
May 20 17:28:13 MYLAPTOP systemd-resolved[1007]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.```

Jean85 avatar May 20 '19 14:05 Jean85

@Jean85 based on your logs, update-systemd-resolved is not getting called on the up command at all, however, /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper is. This seems to be taking over control. Looking at #20 on the OpenVPN tracker, it doesn't support multiple up commands. It also fails silently and there seems to be no interest in fixing it...

Anyway, based on the source code for nm-openvpn-service-openvpn-helper there is support for DNS, WINS (which my script doesn't support), and DOMAIN only:

	for (i = 1; i < 256; i++) {
		char *env_name;

		env_name = g_strdup_printf ("foreign_option_%d", i);
		tmp = getenv (env_name);
		g_free (env_name);

		if (!tmp || strlen (tmp) < 1)
			break;

		if (!g_str_has_prefix (tmp, "dhcp-option "))
			continue;

		tmp += 12; /* strlen ("dhcp-option ") */

		if (g_str_has_prefix (tmp, "DNS "))
			parse_addr_list (dns4_list, dns6_list, tmp + 4);
		else if (g_str_has_prefix (tmp, "WINS "))
			parse_addr_list (nbns_list, NULL, tmp + 5);
		else if (g_str_has_prefix (tmp, "DOMAIN ") && is_domain_valid (tmp + 7))
			g_ptr_array_add (dns_domains, tmp + 7);
	}

However, based on your logs, I see no sign of DOMAIN being passed:

... [...,"MyVPN",21:(tun1)]: Data:   DNS Domain: '(none)'

I only see the only two DNS entries being added: 172.27.0.42 and 172.27.0.33.

... [...,"MyVPN",21:(tun1)]: Data:   Internal DNS: 172.27.0.42
... [...,"MyVPN",21:(tun1)]: Data:   Internal DNS: 172.27.0.33

You should see these under DNS Servers and one of them selected for Current DNS Server when you look at the systemd-resolve --status for tun0. If not, then this should be considered an upstream bug for NetworkManager, as the helper is not sending the correct settings through the DBus connection to NetworkManager (or NetworkManager is not acting on it properly if it is).

Nonetheless, it certainly seems like NetworkManager is incompatible now with update-systemd-resolved and more, not to mention partially broken.

jonathanio avatar May 20 '19 19:05 jonathanio

Thank you for your analysis. As reported before, systemd-resolve --status does not report any DNS apart from the standart ones from my wifi, so yeah, you seem to be correct.

Jean85 avatar May 21 '19 07:05 Jean85

@Jean85 no problem. It's been useful to explore your issue as I understand a little more what NetworkManager does (and doesn't) do. As of 3cef3f3b560d6705197023b67ac64eb2a1176e14 I've added a paragraph warning about it's use with NetworkManager. Until they fix their issues or make some better decisions, it's hard to see where we can both be interoperable.

I'll leave this ticket open for the time being in case @cwray, @frspin, and @adamshand have anything different to add for their cases, or if other people are now experiencing the same problem.

jonathanio avatar May 21 '19 07:05 jonathanio

I've tried to use the CLI openvpn command, but it doesn't seem to work too; your script seems to be triggered correctly, and systemd-resolve --status shows the DNS under the right interface, but a normal dig command sends the query to 127.0.0.53, which I imagine is NM's dnsmasq service... Damn!

Jean85 avatar May 21 '19 08:05 Jean85

Hi @jonathanio, thanks for the response.

I'm on a fairly vanilla Ubuntu 18.04 system, details you requested below. It's worth noting that this is a server and to the best of my knowledge I'm not running Network Manager (please excuse the uncertainty I'm an old sysadmin who is just recently getting used to all this "new fancy stuff" like systemd :-).

tui(adam)$ grep hosts /etc/nsswitch.conf
hosts:          files resolve [!UNAVAIL=return] dns

tui(adam)$ 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

tui(adam)$ systemd-resolve --status
Global
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

<skip a bunch of docker interfaces> 

Link 3 (tun0)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 2 (ens3)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: xxx.61.10.10

# /etc/openvpn/groundtruth.conf
route-nopull
route 10.0.0.0 255.255.0.0
route 10.250.0.0 255.255.0.0
setenv PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
script-security 2
up /etc/openvpn/update-systemd-resolved
down /etc/openvpn/update-systemd-resolved
down-pre
push "dhcp-option DNS 192.168.81.1"
push "dhcp-option DOMAIN groundtruth.co.nz"

# /var/log/syslog
May 23 01:27:27 tui systemd-udevd[18788]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
May 23 01:27:27 tui systemd-networkd[662]: tun0: Gained carrier
May 23 01:27:27 tui networkd-dispatcher[789]: WARNING:Unknown index 599 seen, reloading interface list
May 23 01:27:27 tui ovpn-groundtruth[18780]: /sbin/ip addr add dev tun0 10.8.0.2/24 broadcast 10.8.0.255
May 23 01:27:27 tui systemd-networkd[662]: tun0: Gained IPv6LL
May 23 01:27:27 tui ovpn-groundtruth[18780]: /etc/openvpn/update-systemd-resolved tun0 1492 1550 10.8.0.2 255.255.255.0 init
May 23 01:27:27 tui systemd-timesyncd[652]: Network configuration changed, trying to establish connection.
May 23 01:27:27 tui update-systemd-resolved: Link 'tun0' coming up
May 23 01:27:27 tui openvpn[18780]: WRWWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWWRRWRWR<14>
May 23 01:27:27 update-systemd-resolved: Link 'tun0' coming up
May 23 01:27:27 tui ovpn-groundtruth[18780]: /sbin/ip route add 10.0.0.0/16 via 10.8.0.1
May 23 01:27:27 tui ovpn-groundtruth[18780]: /sbin/ip route add 10.250.0.0/16 via 10.8.0.1
May 23 01:27:27 tui ovpn-groundtruth[18780]: Initialization Sequence Completed
May 23 01:27:27 tui systemd[1]: Starting resolvconf-pull-resolved.service...
May 23 01:27:27 tui systemd[1]: Started resolvconf-pull-resolved.service.
May 23 01:27:27 tui systemd-timesyncd[652]: Synchronized to time server xxx.61.73.243:123 (1.time.constant.com).

adamshand avatar May 23 '19 01:05 adamshand

@adamshand,

On the whole everything for you looks good - The script is loaded correctly (maybe add up-restart to the configuration now, as that will help on partial restarts of the service) and it is being called by OpenVPN on a connection.

I think the main issue is - and I'm assuming that /etc/openvpn/groundtruth.conf is on the client system, not the server configuration, given it includes up and down - that you're using push. push is used by OpenVPN on the server side to push the enclosed configuration down to the client on a connection. If you're using it within the client, just use:

dhcp-option DNS 192.168.81.1
dhcp-option DOMAIN groundtruth.co.nz

and hopefully, on the next restart, it'll add those options into systemd-resolved for you.

jonathanio avatar May 23 '19 06:05 jonathanio

You are correct that this is on the client. I've added up-restart and fixed my dhcp-option lines as you suggest, and ... sure enough, that worked.

Thanks heaps!

Link 600 (tun0)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 192.168.81.1
          DNS Domain: groundtruth.co.nz

adamshand avatar May 24 '19 01:05 adamshand

As a workaround for others who land here, I'm on ubuntu 18.04 and used to use update-systemd-resolved until entropy broke it one day.

I found that NetworkManager itself has a way to prioritize VPN DNS, and seems to have the correct behavior without the update-systemd-resolved script.

Modify your connection like so:

sudo nmcli connection modify VPN_NAME ipv4.dns-priority -42

So your ipv4 section in your /etc/NetworkManager/system-connections file looks like this:

[ipv4]
dns=x.x.x.x;
dns-priority=-42
dns-search=
method=auto

Using this, I see:

$ systemd-resolve --status
Link 12 (tun0)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: x.x.x.x
          DNS Domain: ~.

Caveat: My use case is connecting to one VPN at a time, so this may not be for the general case.

bgemmill avatar Jun 11 '19 20:06 bgemmill

I was able to get this working by running a manual flush of DNS caches in systemd-resolve. Apparently up-restart doesn't clear caches thus you don't get new IP's when querying previous records.

config:

script-security 2
up /etc/openvpn/update-systemd-resolved
up-restart
down /etc/openvpn/update-systemd-resolved
down-pre
dhcp-option DOMAIN-ROUTE .

command: sudo systemd-resolve --flush-caches after starting the VPN

servicecore-developer avatar Apr 10 '20 17:04 servicecore-developer

I was able to get this working by running a manual flush of DNS caches in systemd-resolve. Apparently up-restart doesn't clear caches thus you don't get new IP's when querying previous records.

config:

script-security 2
up /etc/openvpn/update-systemd-resolved
up-restart
down /etc/openvpn/update-systemd-resolved
down-pre
dhcp-option DOMAIN-ROUTE .

command: sudo systemd-resolve --flush-caches after starting the VPN

yes!

javanoclaw avatar Jul 07 '20 12:07 javanoclaw

In my case I didn't have to flush the cache. Adding the dhcp-option DOMAIN-ROUTE . to my config did the work. Thank you! @servicecore-developer

avilesj avatar Aug 27 '20 20:08 avilesj

@servicecore-developer I'm not sure why you mention up-restart in your answer as later you say

command: sudo systemd-resolve --flush-caches after starting the VPN

Once dns cache has been flushed when starting vpn there's no reason to subsequently flush it on every restart. Btw, flushing cache was added in https://github.com/jonathanio/update-systemd-resolved/pull/63 on 19 May 2019; are you using some older version?

piotr-dobrogost avatar Oct 19 '20 12:10 piotr-dobrogost