DNS settings lost on network changes (up-restart enabled)

[timwsuqld]

I believe the issue in #53 are probably the same, just that the fix applied only works in some cases.

I have a laptop that has ethernet and wifi, when any network change occurs, the DNS settings are lost for the VPN tunnel, even if the VPN hasn't been restarted. For example, the VPN is going over the ethernet, the WiFi gets disconnected and reconnected, the settings are then lost.

Status after initial connection

$ systemd-resolve --status tun1
Link 30 (tun1)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 10.1.3.12
          DNS Domain: abc.local

Disconnect wifi, VPN still running via Ethernet, not loss of VPN connection, but DNS settings are lost.

$ systemd-resolve --status tun1
Link 30 (tun1)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Settings in openvpn conf do include up-restart

up /etc/openvpn/update-systemd-resolved
up-restart
down /etc/openvpn/update-systemd-resolved
down-pre

Only relevant syslog lines that I can see are below

Jan  7 07:24:19 SUQLD-L0365 wpa_supplicant[1165]: nl80211: deinit ifname=p2p-dev-wlp3s0 disabled_11b_rates=0
Jan  7 07:24:19 SUQLD-L0365 dnsmasq[1655]: reading /etc/resolv.conf
Jan  7 07:24:19 SUQLD-L0365 dnsmasq[1415]: reading /etc/resolv.conf
Jan  7 07:24:19 SUQLD-L0365 dnsmasq[1415]: using nameserver 127.0.0.53#53
Jan  7 07:24:19 SUQLD-L0365 dnsmasq[1655]: using nameserver 127.0.0.53#53
Jan  7 07:24:19 SUQLD-L0365 NetworkManager[1311]: <info>  [1578353059.5907] audit: op="radio-control" arg="wireless-enabled:0" pid=7938 uid=10006 result="success"
Jan  7 07:24:19 SUQLD-L0365 NetworkManager[1311]: <info>  [1578353059.5909] manager: rfkill: WiFi now disabled by radio killswitch
Jan  7 07:24:19 SUQLD-L0365 dbus-daemon[1138]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.25' (uid=0 pid=1311 comm="/usr/sbin/NetworkManager --no-daemon " label="unconfined")
Jan  7 07:24:19 SUQLD-L0365 systemd[1]: Starting Network Manager Script Dispatcher Service...
Jan  7 07:24:19 SUQLD-L0365 dnsmasq[1415]: reading /etc/resolv.conf
Jan  7 07:24:19 SUQLD-L0365 dnsmasq[1655]: reading /etc/resolv.conf
Jan  7 07:24:19 SUQLD-L0365 dnsmasq[1415]: using nameserver 127.0.0.53#53
...
Jan  7 07:24:19 SUQLD-L0365 dnsmasq[1415]: using nameserver 127.0.0.53#53
Jan  7 07:24:19 SUQLD-L0365 systemd[1]: Started Network Manager Script Dispatcher Service.
Jan  7 07:24:19 SUQLD-L0365 dbus-daemon[1138]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Jan  7 07:24:19 SUQLD-L0365 dnsmasq[1655]: using nameserver 127.0.0.53#53
Jan  7 07:24:19 SUQLD-L0365 dnsmasq[1655]: reading /etc/resolv.conf
Jan  7 07:24:19 SUQLD-L0365 dnsmasq[1655]: using nameserver 127.0.0.53#53
Jan  7 07:24:19 SUQLD-L0365 nm-dispatcher: req:1 'down' [wlp3s0]: new request (2 scripts)
Jan  7 07:24:19 SUQLD-L0365 nm-dispatcher: req:1 'down' [wlp3s0]: start running ordered scripts...
Jan  7 07:24:19 SUQLD-L0365 dnsmasq[1415]: reading /etc/resolv.conf

Running OpenVPN 2.4.4 on Ubuntu 18.04 with update-systemd-resolved (openvpn-systemd-resolved) package version 1.2.7-1. I can't see anything in the 1.3.0 release that would fix this issue.

[vaskokj]

I've got the same exact issue. LTE device that needs to download some images from our main site, causes the ping to go through the roof, silently "drops" the VPN and then DNS doesn't work.

I honestly would say that Ubuntu 18.04 + OpenVPN is completely non-functional in its current state.

[gucki]

See https://github.com/jonathanio/update-systemd-resolved/issues/89 for a potential fix.

[tomeon]

It appears that you are using NetworkManager. There are known issues with certain NetworkManager releases (see here and here). Seems plausible that this is yet another manifestation of NetworkManager naughtiness.

@timwsuqld, @vaskokj, @gucki -- does this remain an issue for you?

[timwsuqld]

@tomeon We've moved away from OpenVPN since I opened this issue, so I don't know if it's still an issue for OpenVPN users. Thanks