NetworkManager isn't pushing DNS server for openvpn connection to systemd-resolved

Bug #1847651 reported by Jonathan Kamens
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

I imported an openvpn configuration with `nmcli c import type openvpn file config.ovpn`.
After doing that, I edited the IPv4 and IPv6 settings for the VPN to turn off automatic DNS servers and specify an IPv4 DNS server IP address explicitly.
I have /usr/lib/NetworkManager/conf.d/10-dns-resolved.conf which contains:

[main]
# We need to specify "dns=systemd-resolved" as for the time being our
# /etc/resolv.conf points to resolvconf's generated file instead of
# systemd-resolved's, so the auto-detection does not work.
dns=systemd-resolved

Given all this, what I believe _should_ happen is when I start the VPN, /run/NetworkManager/no-stub-resolv.conf should be updated to list the DNS server I've specified first, AND NetworkManager should tell systemd-resolved to associate that DNS server with the tun0 network interface created for the VPN.

The former happens, i.e., no-stub-resolv.conf is updated, but the latter doesn't, i.e., systemd-reoslve --status and resolvectl status both do not show the DNS server I've specified in the VPN settings.

As a result, my DNS server is not getting used.

I've hacked this all over the place and I can't figure out _any_ way, when using systemd-resolved mode in NetworkManager, to get it to use my VPN's DNS server when I enable the VPN.

Surely this behavior is not expected?

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: network-manager 1.20.2-1ubuntu1
ProcVersionSignature: Ubuntu 5.3.0-17.18-generic 5.3.1
Uname: Linux 5.3.0-17-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu8
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Oct 10 14:19:17 2019
IfupdownConfig:
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
InstallationDate: Installed on 2019-09-12 (28 days ago)
InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
IpRoute:
 default via 10.204.0.1 dev wlp0s20f3 proto dhcp metric 600
 10.204.0.0/21 dev wlp0s20f3 proto kernel scope link src 10.204.3.73 metric 600
 169.254.0.0/16 dev wlp0s20f3 scope link metric 1000
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
SourcePackage: network-manager
UpgradeStatus: Upgraded to eoan on 2019-09-20 (20 days ago)
nmcli-nm:
 RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN
 running 1.20.2 connected started full enabled enabled enabled enabled enabled

Revision history for this message
Jonathan Kamens (jik) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in network-manager (Ubuntu):
status: New → Confirmed
Revision history for this message
Rudi Servo (rudiservo) wrote :

This is fixed in 20.04

Revision history for this message
Sebastien Bacher (seb128) wrote :

Closing if that's fixed in the current version

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

Other bug subscribers

Remote bug watches

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