DNS server from vpn connection is not being used after network-manager upgrade to 1.2.6

[Lukas Dzunko]

This was initially opened as #1671606 then later duped to #1639776. Discussion in #1639776 indicate that we need new bug for this so I am opening one ... Please don't mark this as duplicate to #1639776 or other similar bug report. We already lost several months and we are again at beginning ...

TL;DR; -> network-manager-1.2.2-0ubuntu0.16.04.4 use DNS defined by VPN (correct). network-manager-1.2.6-0ubuntu0.16.04.1 use DNS from DHCP instead of one defined by VPN (wrong).

DNS resolver should query only DNS servers defined by VPN while connection is active.

=================================

Test steps / result:

- upgraded network-manager to 1.2.6-0ubuntu0.16.04.1 (dnsmasq-base-2.75-1ubuntu0.16.04.2)
- restated my laptop to ensure clean start
- connected to VPN using openconnect / network-manager-openconnect-gnome

Observed results -> DNS queries are forwarded only to DNS servers defined by LAN connection (this is wrong / connection not working at all)

- "killall dnsmasq"
- dnsmasq get automatically restarted by system

Observed results -> most of the the queries are forwarded to DNS servers defined by VPN, but lot of queries get forwarded to DNS servers defined by LAN connection (this is still wrong / DNS leaks, attacker can hijack connection even if VPN is enabled)

- I downgraded back network-manager to 1.2.2-0ubuntu0.16.04.4 (dnsmasq-base stay same)
- restated my laptop to ensure clean test
- connected to same VPN using openconnect

Observed results -> DNS queries are forwarded only to DNS servers defined by VPN connection. There are no leaks to LAN DNS server (this is correct behavior).

=================================

Paul Smith requested additional details in #1639776. Here are:

* If you're using IPv4 vs. IPv6
-> IPv4 only. I have IPv6 set to ignore on all network definition (lan / wifi /vpn)

* If you have checked or unchecked the "Use this connection only for resources on its network"
-> unchecked on all nw definition

* If you have this checked, try unchecking it and see if that makes a difference
-> no change if I toggle this option. Behavior is same.

* When you say "DNS lookups" please be clear about whether the hostnames being looked up are public (e.g., www.google.com or whatever), on your local LAN, or in the network accessed via the VPN. Does it make a difference which one you choose?
-> No difference.

* Are you using fully-qualified hostnames, or relying on the DNS domain search path? Does it make a difference if you do it differently?
-> I normaly use FQDN due to nature of HTTPs cert validation. I don't see difference when I try same using hostname + domain search.

=================================

I am using openconnect (cisco) and openvpn. Test result are by using openconnect but I saw same behaviour also while using openvpn.

=================================

Thanks

Lukas

[Launchpad Janitor (janitor)]

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

[Seumas Finlayson (terry69lawson)]

For weeks now my only workaround for this problem has been to run a terminal script to connect and disconnect the VPN every 20 minutes. This is very inconvenient and impractical for things which require uninterrupted network traffic, so I hope a permanent fix is released ASAP.

[ALinuxUser (buntulongername-new)]

Seumas: since Canonical seem to be dragging their feet on this, you might as well downgrade to network-manager 1.2.2, which is a version that works.

[Lukas Dzunko (lukas-d)]

Seumas: It seems that Canonical simply don't care about VPN users. This is opened for more than two months and still not reasonable response :( ...

... right now there is only one workaround:

- downgrade network manager:
apt-get install network-manager=1.2.2-0ubuntu0.16.04.4

- set it on hold (to prevent updates):
apt-mark hold network-manager

If necessary then reboot machine.

I hope that someone will pick this before they remove 1.2.2. version from repository ...

[Mathieu Trudel-Lapierre (cyphermox)]

I don't know why bugs about "DNS on VPN" were being marked as duplicates of suspend/resume issues in dnsmasq. It's /related/, but definitely not the same thing at all. I can only apologize that this wasn't handled correctly, and try to fix things.

One thing to keep in mind however, is that not all premises on this bug report are correct: what DNS server to use is directly dependent on the settings used in the VPN connection: whether it should use the VPN for everything, or just for the network it provides as routed shipped from the VPN server. Your observations may vary based on what that setting is.

I think we have enough information already to start working on a solution, so I'll mark this bug Triaged/In Progress and assign it to myself. I'm also milestoning it to 17.06; so that it stays on my todo list for this month and June -- but that doesn't mean that it *will* be fixed by then, that will depend on how hard it is to fix and ship the updates where appropriate.

I only have openvpn to work with now, but the actual type of VPN should not matter. If it changes something, *that* would be another bug (and then you should make a separate report). If things work for one VPN plugin, it means NetworkManager is doing what it should.

As soon as there is a proposed fix for this, I'll make it available on a PPA for testing, even before it lands in -proposed, so as to have more certainty that the fix works. I'll comment back here when something is ready.

[Mathieu Trudel-Lapierre (cyphermox)]

Has anyone tried to make their connections with an even newer version of Ubuntu and network-manager, such as on 17.04? That would be a very good test to do (in my experience, it works correctly).

[Aron Bohl (aronbohl)]

I'm running on Ubuntu GNOME 17.04 and I'm still affected by this issue. After connecting to VPN and running a DNS leak test, it still shows my DNS as my usual ISP.

[Mathieu Trudel-Lapierre (cyphermox)]

I don't know what your "DNS leak test" is, but we can't give much weight to that unless we also know a lot more about your config for the VPN and how the test is set up, what it looks for, etc.

[Shawn B (kantlivelong)]

I experience the same issue on 16.04 but it ends up breaking DNS responses entirely because traffic is forced through the OpenVPN tunnel where the DNS resides and the local DNS is no longer accessible.

[ALinuxUser (buntulongername-new)]

I am glad to see that this bug is being worked on and is rightly labelled as being of high importance.

[ALinuxUser (buntulongername-new)]

Might I ask when this rather severe bug is due to be fixed (in Xenial or rather, for me, in Mint)? Thank you.

[Cruz Fernandez (cruz-fernandez)]

On my Ubuntu 17.04 (also happened on 16.10, upgraded to 17.10 that same machine) the bug it's happening to me. My current workaround is to use an equivalent 'openconnect'.

Command issued in my case:

    sudo openconnect --user my-vpn-user --csd-user my-local-unix-user --csd-wrapper ~/csd-wrapper-download.sh --authgroup GROUP_OF_VPN https://remote.corporate.network.com

Another workaround I'm using is to put the internal VPNs IPs on /etc/hosts

[Cruz Fernandez (cruz-fernandez)]

Just expanding a little bit more my last comment, on Ubuntu 17.04, using the 'sudo openconnect xxx' command is adding to the file /run/resolvconf/resolv.conf file the DNS IP addresses as global ones. Just also added them on the 'icon' version and it fixed it too. In Ubuntu 17.04 it's using by default the systemd-resolved service (instead of the reported one dnsmasq).

Maybe we should report a different bug for Ubuntu 17.04 as the packages interaction look to be other ones?

[ALinuxUser (buntulongername-new)]

Cruz, thanks for this.

However, (1) after all the trouble I had getting OpenVPN working, I don't fancy switching to something else (and my system does work at present, using the older version of Network Manager).

Also, (2) I don't really understand what you say about /etc/hosts, though probably I could work it out.

Further, (3) if I understand the last paragraph of your comment #13: I don't know; after all, at the top of this page we can read not only, 'Xenial - In Progress' (though it seems pretty slow progress! It's been at least a month since this show-stopping bug was first reported) but also, 'Yakkety - Triaged'.

[Seumas Finlayson (terry69lawson)]

Any updates? It would be nice to see full closure on this issue ASAP.

[ALinuxUser (buntulongername-new)]

1. It has been four months since this bug - it its original incarnation (https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1671606) - was reported.

2. The bug is critical: it breaks security software.

3. The bug has been reported to Ubuntu, which has paid employees.

4. The bug is a regression and hence presumably not especially hard to fix.

Inference from the conjunction of 1, 2 and 3: *this bug should have been fixed by now*. Yet, it has not. Nor has any explanation been provided as to why not, at least not here. Not has there been a shortage of people asking, politely, for a fix.

Perhaps then a slightly more strident question is in order. To wit: **what gives?** This is the sort of unfixed major problem that drives people back to Windows and Mac OS. (I know that https://bugs.launchpad.net/ubuntu/+bug/1 is closed, but still.)

[ALinuxUser (buntulongername-new)]

Corrections to the above post.

(i) '[I]t its original' should be 'in its original'.

(ii) 'Inference from the conjunction of 1, 2 and 3' should be, 'Inference from the conjunction of 1, 2, 3 and 4' - because I found another reason.

A facility to edit posts would be welcome (but perhaps that exists and I overlook it somehow).

[Andreas Hasenack (ahasenack)]

Using a VPN I have at hand (I don't control the server part of it, though), I can confirm that with n-m 1.2.6 my local DNS (10.0.5.5) is injected after the vpn is established:
Aug 31 20:36:32 31-64 dnsmasq[1118]: setting upstream servers from DBus
Aug 31 20:36:32 31-64 dnsmasq[1118]: using nameserver 10.0.5.5#53(via ens3)
Aug 31 20:36:32 31-64 dnsmasq[1118]: using nameserver 10.172.64.1#53 for domain internal
...

That extra 10.0.5.5 DNS server is not injected when I establish the same connection using n-m 1.2.2.

I have the "Use this connection only for resources on this network" in the ipv4->routes tab NOT checked, i.e., my intention is that all traffic goes through the VPN. And I have method set to "ignore" in the ipv6 settings tab, so it's just ipv4.

[Andreas Hasenack (ahasenack)]

Oh, that box is on xenial, btw.

[martin ehrlich (martin.ehrlich)]

I hope this bug will be fixed soon for 16.04

[Seumas Finlayson (terry69lawson)]

Now NONE of my Ubuntu machines, on Xenial or Zesty, will use my VPN for even a brief time. I've tried several different versions of packages, but nothing. This is absolutely intolerable. Fix this soon Canonical or I will be forced to leave for a different Linux distro.

[ALinuxUser (buntulongername-new)]

@terry69lawson and other frustrated users: perhaps you are in a position to try *WireGuard* as a replacement for OpenVPN (or for other methods of connecting to a VPN). Your VPN provider will need to have WireGuard servers for this to work. If your provider does have such servers, then you are in luck, for not only does Wireguard work with the latest (unfixed) Network Manager, it's also fast and easy. Still, it's also still in development and, though it has had some testing and had good reviews, it is not guaranteed secure.

Still, I am amazed and boggled that Canonical has not fixed the problem. Perhaps it's been fixed in a newer version of Ubuntu and not backported? A bit of information, clearly presented, would not go amiss (@cyphermox)

[Lukas Dzunko (lukas-d)]

@joll-nicholas ... "it is not guaranteed secure." ... Explain this to employer. I am using VPN as it is requirement of my employer. They don't care if it work or not on Linux. M$ Windows client is working and that its. We are not in position to negotiate VPN solution especially if it is not guaranteed to be secure.

Situation is same with my private network. I am using Mikrotik components which have limited amount of VPN options build in. Therefore "WireGuard" is again not an option.

For me it is unbelievable that it is still not fixed and this is not only one bug causing Ubuntu to be useless. ... 14.04 have too old kernel to work with my laptop. 16.04 problems with vpn and terrible flicker on skylake chipset. 17.04 everything around gnuradio completely broken ... maybe it is time to try another distribution ...

[ALinuxUser (buntulongername-new)]

@lukas-d: I understand, but perhaps you are thinking that I work for Canonical or that I have the skill to contribute to the network-manager project. Neither of those things are true. I am a frustrated user (with fairly low programming ability).

It seems to me that switching to a distribution that is not Ubuntu and is not based on Ubuntu might be an idea, in your circumstances.

[Shawn B (kantlivelong)]

Just downgrade network-manager to 1.2.2-0ubuntu0.16.04.4 until the issue is resolved. Pretty simple.

[dlotton (yellow56)]

Just an FYI, I have to downgrade both network-manager=1.2.2-0ubuntu0.16.04.4 and resolvconf=1.78ubuntu2. Doing one or the other would not fix the problem on my system (Linux Mint Mate 18.1).

I'm using a PPTP tunnel.

[ALinuxUser (buntulongername-new)]

On my Mint (18.2 and I think I did it on 18.3 too - both Cinnamon) the
network-manager downgrade sufficed; I did not need to adjust resolvconf.
However, I don't think I was using a 'PPTP tunnel'.

[Lukas Dzunko (lukas-d)]

@joll-nicholas I just want to add my view of this situation to this bug report. :) It was more like message to all in this thread ... my apologize if it was not written properly (I am not native speaker)

@kantlivelong ... yeah, for now (I mentioned this also in initial report) but it may not be case in future. Canonical already removed package for GUI and there is no guarantee that they will leave at least package for daemons there ...

[M.Witte (m-witte-d)]

@cyphermox please comment on the status Mathieu.

Still using the workaround: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1671606

[William Richards (billy229)]

I wonder how many people's DNS leaked over the year this bug hasn't been addressed. Oh well..it's just your users' security. Canonical is a joke. Please stop endangering your users with your incompetence.

[Spencer Seidel (jsseidel)]

I don't know if my issue is related to this or the few others I've seen, so I pre-apologize if this should be moved elsewhere or even if it's not relevant in this context. I'm far from an expert in DNS . . .

My experience was that after upgrading to 16.10 (or higher: it happens in 17.10, too, and I imagine it will in 18.04). DNS lookup for internal sites would fail when I was connected to an openconnect VPN.

In 16.04, my workaround was to comment out dnsmasq in NetworkManager.conf, but in 16.10, 17.04, and 18.04, this option no longer appeared. Also, I additionally had to comment out a reference to a local host in /etc/resolv.conf, which was added below the VPN-only nameservers, which in my case were sufficient. Recently, I tried Fedora 25 and was surprised to see the same issue -- this suggests it's not an Ubuntu-specific problem, unless Canonical is providing some libs that Fedora is using, I don't know.

I found this workaround for my particular case while again searching in a Fedora context for a workaround:

https://www.freedesktop.org/software/systemd/man/nss-resolve.html

TL;DR: I added "resolve [!UNAVAIL=return]" to the hosts line in /etc/nsswitch.conf right before any entry that has "dns" in it. This worked for me in Fedora and Ubuntu both. (Note that in the latest Arch release, this was not an issue for me.)

I'm hoping that this comment will prove helpful to anyone like me who might be searching in vain for a workaround.

[ovv (ovv)]

@jsseidel I believe starting from 16.10 ubuntu use systemd-resolved as dns. Your issues might come from that and it would explain why it's also present in Fedora 25

[Spencer Seidel (jsseidel)]

... and my issue is now resolved in Ubuntu 17.10, at least on a fresh install. Not sure what changed, but no changes are necessary to /etc/nsswitch.conf in order to make resolving DNS work with internal domains while connect to openconnect VPN. Probably I should stick with LTS :-)

[themroc (rauchweihe)]

I have exactly the same Problem like User Orange Shiang-Yuan Kao (orange-kao) wrote on 2017-03-22 in Comment #10 in duplicate Bug 1671606 since upgrading to

Kubuntu 17.10

https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1671606/comments/10

[Roman Vrublevskiy (roman8422)]

As a workaround, I commented out dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf.
Now network manager adds VPN DNS servers to /etc/resolv.conf and everything works as expected.

As an additional benefit, it also adds and uses additional search domains but only with "Use this connection only for resources on its network" unchecked, so all traffic is routed to the tunnel.
With working DNS I can live with it for now.

I'm on Mint 18.3 Cinnamon.

[Daniel Eckl (daniel-eckl)]

This workaround is not bad indeed and saves me, too. But it has drawbacks that people need to know

1) In newer Ubuntu versions, "dnsmasq" is the default DNS option, so the config does not have this option to comment out. Instead you have to set "dns=default" there.

2) With this workaround, some applications need a restart to recognize the new DNS servers after you started VPN. Browsers are a prominent example of reading resolv.conf setup at start and then caching this until restart.

3) The VPN DNS servers are used then, but they are on top of the underlying DNS servers coming from your local DHCP. They are just added to the top of the list. As long as the VPN DNS servers are working, data security is intact. As soon as these stop working, your system might send DNS queries (that maybe should be confidential) to the underlying DNS server.

Issues 2 and 3 are the most dangerous as they can compromise VPN confidentiality.

[Jens Greifenhagen (jgreifenhagen)]

I found another workaround, that works fine without changing package versions or DNS servers.
It is tested with the issues I had with openconnect for NM.

it is "just" killing the dnsmasq instance and it gets restarted automatically which then results in a working system again. It easy and not pretty, but works. Then only (perhaps) noticeable interruption is a few seconds where DNS is not working 15 seconds after the connection has been established:

$ cat /etc/NetworkManager/dispatcher.d/99-openconnect-dnsmasq-bug
#!/bin/bash
set -e
# force restart of dnsmasq on vpn connect

if [[ "$1" =~ "vpn" ]] && [ $2 = "up" ]
then
  if [ -e /var/run/NetworkManager/dnsmasq.pid ]
  then
    $( sleep 15 && /bin/kill -15 $(cat /var/run/NetworkManager/dnsmasq.pid) )
  fi
fi

[code_onkel (code-onkel)]

Will the fix also ensure that the search domain of the VPN's DHCP server will be used?

[dlotton (yellow56)]

By far, the easiest and most effective workaround I've found is commenting out "dns=dnsmasq" in "/etc/NetworkManager/NetworkManager.conf" as a few others have suggested above.

Disappointing that this continues to be an ongoing problem.

[Elladan (elladan)]

The script in #37 didn't work for me, as the interface name was "tun0". The following slightly modified script seems to work OK so far:

# cat 99-openconnect-dnsmasq-bug
#!/bin/bash
set -e
# force restart of dnsmasq on vpn connect
# See https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1688018

echo "Running lame bug 1688018 workaround. Args: $*"

if [[ "$1" =~ "tun0" ]] && [ $2 = "up" ]
then
  if [ -e /var/run/NetworkManager/dnsmasq.pid ]
  then
    /bin/kill -15 $(cat /var/run/NetworkManager/dnsmasq.pid)
  fi
fi

[Pioterus (piotergmoter)]

Almost year old bug still there. This is core functionality of any OS (secure VPNs, DNS) which just does not work on Ubuntu. I don't know how about other distros but I doubt that Ubuntu can claim to be the desktop system with such a bug.

I can confirm that the simplest workaround is comment out dnsmasq in NetworkManager config (ubuntu 16.04). But there are drawbacks of course so this makes the system less secure/reliable in some situations. And of course it took me about 5 hours to figure out what is going on. Those hours could be spend more productive.
P.

[franck (franckweb)]

What happened to this bug? Is it still being addressed? I'm also experiencing the same problem and the solutions above don't work for me :(
----
Ubuntu 16.04.4 LTS
NetworkManager 1.2.6
dnsmasq 2.76

[Pioterus (piotergmoter)]

This bug forced me to search for ubuntu alternatives. I'm looking currently at Manjaro.

About commenting out dns=dnsmasq.
Doing so on laptop (LAN and wifi connections active) has this drawback:
ping my_comp_name
.....unresloved name
adding my_comp_name to /etc/hosts makes the ping my_comp_name working again, but
unplagging RJ45, system changes automatically to wifi connetcion (other IP) and ping my_comp_name again is not working. With dnsmasq enabled the system nicely deals with name resolution so there are no such issues. What happens when the host name resolution is not working ok? System behaves oddly (it delays some operations in many situations).

[Pioterus (piotergmoter)]

Commenting out dnsmasq stopped working. What I have done recently:
https://wiki.ubuntu.com/Kernel/LTSEnablementStack
so my kernel is 4.13 and to my big surprise after connecting with OpenVPN I can resolve host names of my remote site (using host myhost.remote.domain.name), but I cannot ping to them (or krdc to them etc) host unknown and thats it. What is going on?

[Egor Tensin (egor-tensin)]

I had a lot of trouble with NetworkManager+OpenVPN on Ubuntu and discovered a couple of workarounds.

If you're having trouble resolving internal domain names (like *.internal.company.com), you might want to try adding something like this to the [ipv4] section in /etc/NetworkManager/system-connections/YOUR_VPN_CONNECTION:

    dns-search=internal.company.com;

If you want to direct all DNS lookups through your VPN, try adding

    dns-priority=-1

to the same section. But this will disable all DNS servers except for the VPN, so if you have a local DNS server, local domain names will stop resolving.

I'm using Ubuntu 18.04 & network-manager 1.10.6-2ubuntu1.

I'll duplicate this message in #1671606.

[Egor Tensin (egor-tensin)]

> Comment here only if you think the duplicate status is wrong.

Or I won't.

[Yale Huang (yale-huang)]

@egor-tensin Thanks. Your walk-around works.

[Aron Bohl (aronbohl)]

Thank you @egor-tensin! I've been struggling with this problem for years. This is the first work around that actually works! I added that line under the [ipv4] section of my VPN connection file and then restarted the network manager with:

   sudo systemctl restart NetworkManager.service

Now it's actually using the DNS specified by the VPN rather than just my default ISP's DNS.

[Anton Melser (melser-anton)]

@egor-tensin you are awesome! I think there might be a few related problems (like https://github.com/systemd/systemd/issues/7182) but this seems to actually work. I actually saw this bug but didn't click that your fix would work until having wasted a huge amount of time.

Some one from Ubuntu should DEFINITELY put this in the NetworkManager FAQ. And it should obviously be a GUI option - it is rather shameful that we still have to generate our configs with code because the GUI is so broken...

[DaMoisture (hckrmagoo)]

THank you Egor! that did the trick on Kubuntu 18.04. Now if I could only figure out why it disconnects from the VPN after .5-2 hours...

[Egor Tensin (egor-tensin)]

@hckrmagoo I had this problem as well, try making NetworkManager run OpenVPN as root: https://askubuntu.com/a/906055/844205.

[DaMoisture (hckrmagoo)]

Well, that was pretty straightforward! Thanks for pointing that one out, we'll know in a couple hours if it worked.

Peace & Joy; Love & Gratitude

[DaMoisture (hckrmagoo)]

Thanks Egor! Connection stayed up all day!!

[javierpb (javiplx)]

I'm experiencing this issue on Ubuntu 18.04.1. In case this helps anyone, I've been able to fix following https://wiki.archlinux.org/index.php/OpenVPN#Update_systemd-resolved_script. Only after that change the OpenVPN supplied DNS servers appear on `systemd-resolve --status`. In case that matters, I run `openvpn` from command line

[ghomem (gustavo)]

This problem:

https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1688018/comments/18

remains and now the old package 1.2.2-0ubuntu0.16.04.4 is not available anymore. Can we go back to the behaviour of 1.2.2-0ubuntu0.16.04.4 ?

[Tiago Maurício (tiagolcmauricio)]

I am running Ubuntu 16.04 with plasma. I was experiencing this issue and downgraded the network-manager package to 1.2.2-0ubuntu0.16.04.4. Since the downgrade I haven't had any trouble. Waiting for fix in the latest version :)

[Pioterus (piotergmoter)]

Sebastien, could you explain the 'status: Triaged → Won't Fix' meaning?

Is this bug going to stay with us or what?

[Colin Law (colin-law)]

It has only been marked Won't Fix in Yakkety, because Yakkety is well past it's sell by date. It is still open on Xenial.

[Pioterus (piotergmoter)]

Thanx Colin.
Anyway anyone knows why this bug is sooo hard to fix? It is old, and quite blocking someones workflow.

[dlotton (yellow56)]

For those using OpenVPN, I discovered that there is a package named 'openvpn-systemd-resolvd' that finally resolved this issue for me. Here's the synopsis for the package in the repo...

"This is a helper script designed to integrate OpenVPN with the
systemd-resolved service via DBus instead of trying to override
/etc/resolv.conf, or manipulate systemd-networkd configuration files.

Since systemd-229, the systemd-resolved service has an API available via DBus
which allows directly setting the DNS configuration for a link. This script
makes use of busctl from systemd to send DBus messages to systemd-resolved to
update the DNS for the link created by OpenVPN."

[Taran M (benzidrine)]

This bug and the fact that there seems to be no care in fixing it made me leave the Ubuntu distro behind. Pathetic. I no longer care if you fix it or not.

[Dmitrii Shcherbakov (dmitriis)]

On 19.04 I can see the following (correct) behavior.

With VPN (turned on via NetworkManager):

# note: no "global" DNS servers have been configured by hand through systemd-resolved conf using "DNS=" directive

systemd-resolved --status

# ...

Link 15 (tun0)
      Current Scopes: DNS
DefaultRoute setting: yes
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
  Current DNS Server: <vpndns1>
         DNS Servers: <vpndns1>
                      <vpndns2>
          DNS Domain: ~.

Link 2 (wlp59s0)
      Current Scopes: DNS
DefaultRoute setting: yes
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
  Current DNS Server: <local-dhcp-dns1>
         DNS Servers: <local-dhcp-dns1>
                      <local-dhcp-dns2>
          DNS Domain: deadbeefcafe

Without VPN:

systemd-resolved --status
# ...

Link 2 (wlp59s0)
      Current Scopes: DNS
DefaultRoute setting: yes
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
  Current DNS Server: <local-dhcp-dns1>
         DNS Servers: <local-dhcp-dns1>
                      <local-dhcp-dns2>
          DNS Domain: ~.
                      deadbeefcafe

"~." configuration goes to the tun0 interface once VPN is enabled and is removed from the physical interface. In this example it means that DHCP-advertised local DNS servers will be used for deadbeefcafe domain only and everything else will go through the DNS servers of a VPN service.

Clarifications on how "~." affects DNS request routing:

https://github.com/systemd/systemd/blame/v240/src/resolve/resolved-dns-scope.c#L1411-L1418
                 * "~." really trumps everything and clearly indicates that this interface shall receive all
                 * traffic it can get. */
http://manpages.ubuntu.com/manpages/disco/man5/resolved.conf.5.html#options
https://www.freedesktop.org/software/systemd/man/resolved.conf.html#Domains=

Packages:

ii network-manager 1.16.0-0ubuntu2 amd64 network management framework (daemon and userspace tools)
ii network-manager-config-connectivity-ubuntu 1.16.0-0ubuntu2 all NetworkManager configuration to enable connectivity checking
ii network-manager-gnome 1.8.20-1ubuntu1 amd64 network management framework (GNOME frontend)
ii network-manager-openvpn 1.8.10-1 amd64 network management framework (OpenVPN plugin core)
ii network-manager-openvpn-gnome 1.8.10-1 amd64 network management framework (OpenVPN plugin GNOME GUI)
ii netplan.io 0.97-0ubuntu1~19.04.1 amd64 YAML network configuration abstraction for various backends
ii systemd 240-6ubuntu5.3 amd64 system and service manager

I have also captured DNS packets on all in...

[Vadym K (hmvs)]

18.04.3 LTS !, still reproduced, which makes me sad.

As a workaround: `sudo apt-get install resolvconf-admin`

[sokai (sokai)]

Hi!

@Vadym K (hmvs): What is your workaround good for?

In general:
I'm also effected by this bug on 18.04.3 (NetworkManager v1.10.14) and can't see any 'official' solution (for Bionic). – Can someone maybe help (me)?

Thanks and KR!

[Dan Streetman (ddstreet)]

> I'm also effected by this bug on 18.04.3 (NetworkManager v1.10.14)

please note that n-m version 1.10.14 never was released out of Bionic-proposed; instead smaller fixes were used to address specific bugs, and the latest NetworkManager version in Bionic-updates is 1.10.6-2ubuntu1.2. If you have version 1.10.14 installed, you should remove and reinstall it, or simply 'downgrade' it with apt to the latest released version.

[Michael Ekoka (verysimple)]

The silence regarding this problem is a bit disconcerting. After jumping through many hoops, I managed to resolve this with the help of this answer: https://forum.manjaro.org/t/weird-dns-issue-over-vpn/78092/11

I deleted the /etc/resolv.conf symlink and disabled systemd-resolved as instructed, then rebooted. After start up, NetworkManager re-created a file at /etc/resolv.conf (not a symlink this time). Although I could connect to the Internet, I coulnd't access any website. I inferred some DNS issues and I simply re-enabled systemd-resolved.

$ sudo systemctl enable systemd-resolved.service

I recreated the symlink pointing /etc/resolv.conf to /run/resolvconf/resolv.conf

$ sudo ln -s /run/resolvconf/resolv.conf /etc/resolv.conf

then I rebooted once again.

Next time I connected to the VPN, I could access its resources with no further issues.

[Adam Adamski (adamadamski)]

I'm on Ubuntu 20.04 and I've tried every solution listed above and in the bug's duplicate and none of them worked... It's really disappointing that dns doesn't work with VPNs for over 4 years.

[Adam Adamski (adamadamski)]

Ah, I forgot to mention I've found a somewhat working workaround. If you uncomment the line "DNS" in /etc/systemd/resolved.conf and put list of DNSes with first VPN's DNS then your normal DNS, then it will always try to go through the VPN's DNS first even if you're not trying to access a resource from the VPN. Be careful not to type any dangerous domain names when connected to the VPN though.