DNS and search domain is not pushed to systemd-resolved sometimes

Bug #1691996 reported by Lastique on 2017-05-19
This bug affects 3 people
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)

Bug Description

I have an OpenVPN connection with statically configured DNS server address and the search domain. When this connection is established, there is a high chance that the DNS address and the search domain are not pushed to systemd-resolved for this connection. The problem does not reproduce reliably, sometimes the parameters are pushed. When the parameters are not pushed, 'systemd-resolve --status' reports no DNS servers or DNS domain for the VPN connection, and name resolution does not work.

This bug has been reportedly fixed upstream in NetworkManager 1.8. The upstream bug reports are:


Please, update NetworkManager shipped with Ubuntu or backport the fix.

ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: network-manager 1.4.4-1ubuntu3
Uname: Linux 4.10.0-16.1-liquorix-amd64 x86_64
NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
ApportVersion: 2.20.4-0ubuntu4
Architecture: amd64
CurrentDesktop: KDE
Date: Fri May 19 13:35:42 2017
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
InstallationDate: Installed on 2015-05-01 (748 days ago)
InstallationMedia: Kubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422)
 default via dev eth0 proto static metric 100 dev virbr0 scope link metric 1000 linkdown dev eth0 proto kernel scope link src metric 100 dev virbr0 proto kernel scope link src linkdown
 0: hci0: Bluetooth
  Soft blocked: no
  Hard blocked: no
SourcePackage: network-manager
UpgradeStatus: Upgraded to zesty on 2017-04-16 (33 days ago)
mtime.conffile..etc.NetworkManager.NetworkManager.conf: 2017-05-11T15:26:12.449289
 virbr0 bridge connected /org/freedesktop/NetworkManager/Devices/2 virbr0 a80bff56-e5d6-4fa4-b544-89cb3c389e3b /org/freedesktop/NetworkManager/ActiveConnection/0
 eth0 ethernet connected /org/freedesktop/NetworkManager/Devices/1 Wired connection 1 44a70bab-e44e-3942-8259-e96eb6f3fe5b /org/freedesktop/NetworkManager/ActiveConnection/2
 lo loopback unmanaged /org/freedesktop/NetworkManager/Devices/0 -- -- --
 virbr0-nic tun unmanaged /org/freedesktop/NetworkManager/Devices/3 -- -- --
 running 1.4.4 connected started full enabled enabled enabled enabled enabled

Lastique (andysem) wrote :
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in network-manager (Ubuntu):
status: New → Confirmed

The DNS for the tun0 of my OpenVPN connection completely fails. There's nothing in systemd-resolve --status or /var/run/resolv.conf or /etc or any of the other usual places; I don't have time to go digging so I shove stuff in /etc/hosts for now.
Pretty useless state of affairs, all told...

Tomasz Kontusz (tomasz-kontusz) wrote :

~jonathanharker could you check if `nmcli connection show 'CONNECTION NAME' | grep DNS` shows the nameservers you expect? You can list connection names with `nmcli connection`. This way we'll make sure if the problem happens between NM and the VPN or NM and resolved (for me it was the latter, and the attached patch fixed it).

The attachment "Port of patch from Patch from https://bugzilla.gnome.org/show_bug.cgi?id=779087 to network-manager 1.4.4-1ubuntu3.1" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Sebastien Bacher (seb128) wrote :

The issue is fixed in Ubuntu 17.10, it's not likely to get SRUed to the previous stable now though

Changed in network-manager (Ubuntu):
importance: Undecided → High
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.