NetworkManager 1.10.6-2ubuntu1.2 breaks VPN DNS

Bug #1851407 reported by Joe Hohertz
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

NetworkManager as of 1.10.6-2ubuntu1.2 has cause a regression whereby a VPN connection which sets it's dns-priority to a negative value, which should cause the DNS server supplied by the DNS connection to be placed first, instead now refuses to place the DNS server into the resolver under any circumstance.

Pinning the 1.10.6-2ubuntu1.1 works around the issue.

I suspect the fix-dns-leak-lp1754671.patch has caused this regression.

This patch should be reverted as soon as possible to restore proper functionality of network manager with respect to VPN servers with DNS resolvers.

$ lsb_release -rd
Description: Ubuntu 18.04.3 LTS
Release: 18.04

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
Dariusz Gadomski (dgadomski) wrote :

Joe, thanks for reporting the bug.
I am unable to reproduce the issue in my test env.

Can you please provide a step-by-step procedure to reproduce it on a clean 18.04 installation?

Thanks.

Revision history for this message
Joe Hohertz (jhohertz) wrote :

1) Add an openvpn connection, which emits DHCP DNS servers, and is flagged "use only for resources on this connection"
2) Add a negative dns_priority to the connection via CLI or editing the connection

Prior to the change, this worked fine, you could connect, and the indicated DNS server would become prioritised.

After the change, this no longer works, and networkmanager will not associate a DNS server to the connection at all.

Revision history for this message
Skashmeri (skashmeri) wrote :

I had the exact same issue, upon upgrading I got the same issues as jhohertz, I followed the above instructions and the issue was fixed.

Revision history for this message
Dariusz Gadomski (dgadomski) wrote :

Joe, I still can't reproduce your issue.
Can you please verify against what I'm trying:
1. Setup a VPN that provides DNS via DHCP
2. Connect to that VPN and verify DNS by:
$ systemd-resolve --status
(...)
Link 4 (tun0)
(...)
DNS Servers: X.X.X.X
(...)
3. Disconnect VPN and edit connection:
$ nmcli connection edit myvpn
nmcli> set ipv4.dns-priority -30
nmcli> save
$ nmcli connection show myvpn | grep dns-priority
ipv4.dns-priority: -30
ipv6.dns-priority: 0

4. Re-connect to VPN and try to reach a name within the VPN:
$ dig some.host.in.my.vpn

I have used:
$ apt-cache policy network-manager
network-manager:
  Installed: 1.10.6-2ubuntu1.2

Please tell me in which of the steps in your case network-manager behaves differently.

tags: added: regression-update
Revision history for this message
Joe Hohertz (jhohertz) wrote :

Did you ensure that the connection was set for "use only for resources on the connection"? (I believe this may be ipv4.never-default=yes setting in nmcli... and only bring it up because you do not mention it.)

I also think the negative DNS priority might be historical, no longer needed. (I just noticed mine was set to 50, which I believe is default for VPN connections now)

I should also note that if the never-default is set to "no"... I *will* see the DNS server, however the routing is then incorrect as the VPN concerned doesn't provide public routes.

So to be clear... never-default needs to be set to yes... DNS we expect is from DHCP options sent from the VPN server, and the problem is that you will see NO DNS servers for tun0 when you run the 'systemd-resolve --status' command

Revision history for this message
Dariusz Gadomski (dgadomski) wrote :

Thanks Joe.

There has to be another factor coming into play, as my setup contains "use only for resources on its network".

$ nmcli connection show my-vpn | grep -e ipv4.never-default -e ipv4.dns-priority
ipv4.dns-priority: -30
ipv4.never-default: yes

Are you able to test this on Ubuntu 19.10?
It does not have the patch and in my tests it's consistent with what I observe on the patched 18.04.

Revision history for this message
Joe Hohertz (jhohertz) wrote :

I can possibly try 19.10 later, however at the moment I only have my LTS laptop to test with.

Just to ensure we've covered any variations, here is a redacted version of my connection file, in case I have missed anything.

[connection]
id=Vxxxxxxx
uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
type=vpn
permissions=user:xxxxxxxx:;
timestamp=1572967683

[vpn]
auth=SHA512
ca=/home/xxxxxxxx/.cert/nm-openvpn/xxx-ca.pem
cert=/home/xxxxxxxx/.cert/nm-openvpn/xxx-cert.pem
cert-pass-flags=0
cipher=AES-256-CBC
comp-lzo=adaptive
connection-type=password-tls
dev=tun
key=/home/xxxxxxxx/.cert/nm-openvpn/xxx-key.pem
password-flags=2
remote=1.vpn.xxxxxxxx.xxx
remote-cert-tls=server
reneg-seconds=604800
ta=/home/xxxxxxxx/.cert/nm-openvpn/xxx-tls-auth.pem
ta-dir=1
username=xxxxxx
service-type=org.freedesktop.NetworkManager.openvpn

[ipv4]
dns-priority=50
dns-search=
method=auto
never-default=true

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto

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.