DNS resolution fails when using VPN and routing all traffic over it

Could you include what gets written to your syslog while the VPN connection is established?

SIGUSR1 to dnsmasq tells you what server it's talking to, but unfortunately not for what domain...

Based on your described symptoms, I'm suspecting that the openvpn plugin told NM to configure dnsmasq only for the domains pushed by the VPN server rather than for all domains (as it should when you route everything over the VPN).

If that's what happened, you should see log lines like:
Jul 18 22:14:06 castiana dnsmasq[9394]: using nameserver 172.16.20.30#53 for domain stgraber.net
Jul 18 22:14:06 castiana dnsmasq[9394]: using nameserver 172.16.20.30#53 for domain 16.172.in-addr.arpa
Jul 18 22:14:06 castiana dnsmasq[9394]: using nameserver 172.16.20.30#53 for domain 17.172.in-addr.arpa
Jul 18 22:14:06 castiana dnsmasq[9394]: using nameserver 172.16.20.30#53 for domain 18.172.in-addr.arpa
Jul 18 22:14:06 castiana dnsmasq[9394]: using nameserver 172.16.20.30#53 for domain 19.172.in-addr.arpa
Jul 18 22:14:06 castiana dnsmasq[9394]: using nameserver 172.16.20.30#53 for domain 22.172.in-addr.arpa
Jul 18 22:14:06 castiana dnsmasq[9394]: using nameserver 172.16.20.30#53 for domain 56.149.in-addr.arpa
Jul 18 22:14:06 castiana dnsmasq[9394]: using nameserver 172.16.20.31#53 for domain stgraber.net
Jul 18 22:14:06 castiana dnsmasq[9394]: using nameserver 172.16.20.31#53 for domain 16.172.in-addr.arpa
Jul 18 22:14:06 castiana dnsmasq[9394]: using nameserver 172.16.20.31#53 for domain 17.172.in-addr.arpa
Jul 18 22:14:06 castiana dnsmasq[9394]: using nameserver 172.16.20.31#53 for domain 18.172.in-addr.arpa
Jul 18 22:14:06 castiana dnsmasq[9394]: using nameserver 172.16.20.31#53 for domain 19.172.in-addr.arpa
Jul 18 22:14:06 castiana dnsmasq[9394]: using nameserver 172.16.20.31#53 for domain 22.172.in-addr.arpa
Jul 18 22:14:06 castiana dnsmasq[9394]: using nameserver 172.16.20.31#53 for domain 56.149.in-addr.arpa

And resolution of any of record that's part of one of those domains would succeed.

https://pastebin.canonical.com/161179/

Good guess; that's exactly right.

| james@ornery:~$ dig +short @127.0.1.1 osmium-host.ppa
| 10.222.37.176
| james@ornery:~$ dig +short @127.0.1.1 www.openbsd.org
| james@ornery:~$

I just ran into this on a new 16.04 laptop as well.

I was pointed at this bug by Stéphane, and looked again with some extra logging patched in. I'm under the impression that NM is doing exactly as it's told, which also means dnsmasq will do the same: it's simply not configuring a "global" nameserver to go with the per-domain ones.

From what I can tell after careful testing with the debug logs enabled and watching what NM and dnsmasq say to each other, it looks like this failure scenario happens when you configure the IPv4 settings to "Use this connection only for the resources on its network" (ie. split-tunnelling), but don't enable the same option for the IPv6 settings.

That state appears to confuse NM into thinking it shouldn't set the "global" DNS because one of the connections is meant to take the default gateway.

I'm still looking at the code to figure out how best to make this work as expected, but I think in the meantime a good workaround would be to mirror the split-tunnelling option in IPv4 and IPv6 settings (the checkbox "Use this connection..."). You may then put IPv6 back to "Ignore" or leave it as-is, since if there are no IPv6 addresses given by the VPN this will simply be ignored.

So I just ran into the exact same problem with my personal VPN when I do have both IPv4 and IPv6 configured to route all traffic over the VPN.

Please provide any extra information you can to reproduce and debug this issue. I can't reproduce it. If both IPv4 and IPv6 are set to not take the default route, things are behaving correctly here; just like the DNS settings are correctly configured when no split-tunnelling is in use at all.

Also note that this will not work if dns=dnsmasq isn't set; this is important as some versions of NetworkManager have disabled that feature.

From my logs; calling on to kill -USR1 dnsmasq before doing any tests (5 sent to local (192.168.0.1), 0 to the VPN (10.x.x.1) DNS):

ug 19 14:04:30 demeter NetworkManager[2922]: <debug> [1471629870.6888] dnsmasq[0x5580dd157040]: dnsmasq update successful
Aug 19 14:05:16 demeter dnsmasq[5238]: horodatage 1471629916
Aug 19 14:05:16 demeter dnsmasq[5238]: taille de cache 0, 0/0 insertions dans le cache entrées non-expirées réutilisées
Aug 19 14:05:16 demeter dnsmasq[5238]: requêtes transmises 40322, requêtes résolues localement 448
Aug 19 14:05:16 demeter dnsmasq[5238]: queries for authoritative zones 0
Aug 19 14:05:16 demeter dnsmasq[5238]: serveur 192.168.0.1#53: requêtes envoyées 5, requêtes réessayées ou échouées 0
Aug 19 14:05:16 demeter dnsmasq[5238]: serveur 10.x.x.1#53: requêtes envoyées 0, requêtes réessayées ou échouées 0
Aug 19 14:05:49 demeter dnsmasq[5238]: horodatage 1471629949
Aug 19 14:05:49 demeter dnsmasq[5238]: taille de cache 0, 0/0 insertions dans le cache entrées non-expirées réutilisées
Aug 19 14:05:49 demeter dnsmasq[5238]: requêtes transmises 40324, requêtes résolues localement 448
Aug 19 14:05:49 demeter dnsmasq[5238]: queries for authoritative zones 0
Aug 19 14:05:49 demeter dnsmasq[5238]: serveur 192.168.0.1#53: requêtes envoyées 7, requêtes réessayées ou échouées 0
Aug 19 14:05:49 demeter dnsmasq[5238]: serveur 10.x.x.1#53: requêtes envoyées 0, requêtes réessayées ou échouées 0
Aug 19 14:06:06 demeter dnsmasq[5238]: horodatage 1471629966
Aug 19 14:06:06 demeter dnsmasq[5238]: taille de cache 0, 0/0 insertions dans le cache entrées non-expirées réutilisées
Aug 19 14:06:06 demeter dnsmasq[5238]: requêtes transmises 40325, requêtes résolues localement 448
Aug 19 14:06:06 demeter dnsmasq[5238]: queries for authoritative zones 0
Aug 19 14:06:06 demeter dnsmasq[5238]: serveur 192.168.0.1#53: requêtes envoyées 7, requêtes réessayées ou échouées 0
Aug 19 14:06:06 demeter dnsmasq[5238]: serveur 10.x.x.1#53: requêtes envoyées 1, requêtes réessayées ou échouées 0

Followed by tries to resolve www.google.com (local), www.canonical.com (local), at which point you reached 7/0; then lcy01.buildd (intended for the VPN), which brings the status up to 7/1. The only one that went to the VPN was the request for lcy01.buildd; and it was rejected NXDOMAIN (and didn't go to the local DNS at all). Everything happened as intended.

I can still reproduce this and I've double checked that my IPv4 and v6
settings are identical in terms of both the 'Method' filed (set to
'Automatic VPN' for both) and that both are set to accept all routes
from the VPN server.

Logs are here: https://pastebin.canonical.com/164434/

cyphermox asked me for receipts!

  http://people.canonical.com/~james/nm-settings/

I'm running into the same issue. My network doesn't have IPv6 although its configured to try, turning off IPv6 had no effect.

If I direct all traffic through the VPN ('Use this connection only for resources on its network' in the routes window is left unchecked) I get a DNS server but its not used by default

$ dig @127.0.1.1 +short chaos txt servers.bind
"10.172.64.1#53 12 0"
$ dig google.com +short
# No result returned
$ dig google.com +short @10.172.64.1
172.217.4.174

If I only direct VPN traffic for resources on the VPN network('Use this connection only for resources on its network' in the routes window is checked) on BOTH IPv4 and IPv6 I get two DNS servers and DNS seems to work.

$ dig @127.0.1.1 +short chaos txt servers.bind
"192.168.1.1#53 6 0" "10.172.64.1#53 0 0"
$ dig google.com +short
216.58.216.174

So it seems network manager is adding the VPN DNS server but its not using it.

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

I see this with IPv6 disabled completely on the laptop:

$ cat /etc/sysctl.d/99-noipv6.conf
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

I can confirm that both ipv4 and ipv6 settings have both 'Use this connection only for resources on its network' and 'Ignore automatically obtained routes' disabled, and when I try connecting the ipv6 method is 'ignore'.