Comment 81 for bug 1624317

Nicholas Stommel (nstommel) wrote :

I have successfully backported Thomas Haller's excellent upstream solution as detailed in This took some time as things have changed quite a bit upstream, but the patch works on the current zesty 17.04 1.4.4-1ubuntu3.1 network-manager! This is a much better fix than the stopgap SetLinkDomains "." bus call based on link type I included in the previous patch. It should be reviewed for current application/submission to the package maintainers as it is basically a direct backport of Haller's fix merged upstream.

NOTE: You MUST set the ipv4.dns-priority to a negative number for the network-manager to unseat DNS configurations for other non-VPN interfaces. This patch allows for correct behavior with negative ipv4.dns-priority: "Negative values have the special effect of excluding other configurations with a greater priority value; so in presence of at least a negative priority, only DNS servers from connections with the lowest priority value will be used." Usage of a negative dns-priority disables DNS configuration for all other interfaces, ensuring there are no DNS leaks over a VPN connection using systemd-resolved. Before Haller's bugfix, this feature did not work with systemd-resolved.

To set the ipv4.dns-priority, open the VPN connection profile you have configured through NM like so:
sudo nano /etc/NetworkManager/system-connections/<VPN-con-profile-name-here>
and adding the line (value of -42 recommended by Haller) "dns-priority=-42" so that the file contains something like:


Alternatively, use the command
sudo nmcli connection modify "<VPN-con-profile-name-here>" ipv4.dns-priority -42
And you should see that the config file for that connection contains the same line as shown above. After doing so and patching/installing the patched network manager, you should not experience DNS leaks.

When I am connected to PIA's servers through network-manager-openvpn using the patched network manager and a negative ipv4.dns-priority set for my VPN connection, the output of systemd-resolved looks like this (notice that the Verizon ISP DNS server was 'unseated' and is absent for the primary wireless link wlo1):

          DNSSEC NTA:
                      ...(long list of NTAs omitted)...

Link 4 (tun0)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers:

Link 2 (wlo1)
      Current Scopes: LLMNR/IPv4 LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

If anyone is curious about support for the routing-only domain in NM, see the following bug which is about adding support for routing-only domains for systemd-resolved (still work in progress).