DNS resolution of VPN hosts stopped working

[gpothier]

I have been using 17.04 for a few weeks now, but a recent update seems to have broken DNS resolution for VPN hosts. The local network is 192.168.50.*, with DNS at 192.168.50.2. The remote network is 192.168.0.*, with DNS at 192.168.0.2. I can ping remote hosts, but I can't resolve their names, although syslog says the following:

systemd-resolved[2865]: Switching to DNS server 192.168.0.2 for interface tun0.

The remote DNS domain is ozone.caligrafix.cl. Here is what does and doesn't work, using a valid remote host name (cali00):

dig cali00: fails
dig cali00.ozone.caligrafix.cl: fails
dig cali00 @192.168.0.2: works
dig cali00.ozone.caligrafix.cl @192.168.0.2: works

Here is the complete log of VPN connection setup:

Feb 18 11:56:34 tadzim3 NetworkManager[2242]: <info> [1487429794.9928] audit: op="connection-activate" uuid="ae3693ea-df59-414e-95a8-bf280a65b8db" name="cali-fw" pid=4439 uid=1000 result="success"
Feb 18 11:56:34 tadzim3 NetworkManager[2242]: <info> [1487429794.9976] vpn-connection[0x5622aa56c370,ae3693ea-df59-414e-95a8-bf280a65b8db,"cali-fw",0]: Started the VPN service, PID 7173
Feb 18 11:56:35 tadzim3 NetworkManager[2242]: <info> [1487429795.0048] vpn-connection[0x5622aa56c370,ae3693ea-df59-414e-95a8-bf280a65b8db,"cali-fw",0]: Saw the service appear; activating connection
Feb 18 11:56:35 tadzim3 NetworkManager[2242]: <info> [1487429795.1165] vpn-connection[0x5622aa56c370,ae3693ea-df59-414e-95a8-bf280a65b8db,"cali-fw",0]: VPN plugin: state changed: starting (3)
Feb 18 11:56:35 tadzim3 NetworkManager[2242]: <info> [1487429795.1170] vpn-connection[0x5622aa56c370,ae3693ea-df59-414e-95a8-bf280a65b8db,"cali-fw",0]: VPN connection: (ConnectInteractive) reply received
Feb 18 11:56:35 tadzim3 nm-openvpn[7180]: OpenVPN 2.4.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 10 2017
Feb 18 11:56:35 tadzim3 nm-openvpn[7180]: library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08
Feb 18 11:56:35 tadzim3 nm-openvpn[7180]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Feb 18 11:56:35 tadzim3 nm-openvpn[7180]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Feb 18 11:56:35 tadzim3 nm-openvpn[7180]: TCP/UDP: Preserving recently used remote address: [AF_INET]186.103.161.74:25402
Feb 18 11:56:35 tadzim3 nm-openvpn[7180]: UDP link local: (not bound)
Feb 18 11:56:35 tadzim3 nm-openvpn[7180]: UDP link remote: [AF_INET]186.103.161.74:25402
Feb 18 11:56:35 tadzim3 nm-openvpn[7180]: NOTE: chroot will be delayed because of --client, --pull, or --up-delay
Feb 18 11:56:35 tadzim3 nm-openvpn[7180]: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Feb 18 11:56:36 tadzim3 nm-openvpn[7180]: [cali-fw-vpn] Peer Connection Initiated with [AF_INET]186.103.161.74:25402
Feb 18 11:56:37 tadzim3 nm-openvpn[7180]: TUN/TAP device tun0 opened
Feb 18 11:56:37 tadzim3 nm-openvpn[7180]: /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper --debug 0 7173 --bus-name org.freedesktop.NetworkManager.openvpn.Connection_6 --tun -- tun0 1500 1558 10.8.1.2 255.255.255.0 init
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.1267] manager: (tun0): new Tun device (/org/freedesktop/NetworkManager/Devices/7)
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.1368] devices added (path: /sys/devices/virtual/net/tun0, iface: tun0)
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.1368] device added (path: /sys/devices/virtual/net/tun0, iface: tun0): no ifupdown configuration found.
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.1443] vpn-connection[0x5622aa56c370,ae3693ea-df59-414e-95a8-bf280a65b8db,"cali-fw",0]: VPN connection: (IP Config Get) reply received.
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.1463] vpn-connection[0x5622aa56c370,ae3693ea-df59-414e-95a8-bf280a65b8db,"cali-fw",8:(tun0)]: VPN connection: (IP4 Config Get) reply received
Feb 18 11:56:37 tadzim3 nm-openvpn[7180]: chroot to '/var/lib/openvpn/chroot' and cd to '/' succeeded
Feb 18 11:56:37 tadzim3 nm-openvpn[7180]: GID set to nm-openvpn
Feb 18 11:56:37 tadzim3 nm-openvpn[7180]: UID set to nm-openvpn
Feb 18 11:56:37 tadzim3 nm-openvpn[7180]: Initialization Sequence Completed
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.1504] vpn-connection[0x5622aa56c370,ae3693ea-df59-414e-95a8-bf280a65b8db,"cali-fw",8:(tun0)]: Data: VPN Gateway: 186.103.161.74
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.1505] vpn-connection[0x5622aa56c370,ae3693ea-df59-414e-95a8-bf280a65b8db,"cali-fw",8:(tun0)]: Data: Tunnel Device: "tun0"
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.1505] vpn-connection[0x5622aa56c370,ae3693ea-df59-414e-95a8-bf280a65b8db,"cali-fw",8:(tun0)]: Data: IPv4 configuration:
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.1505] vpn-connection[0x5622aa56c370,ae3693ea-df59-414e-95a8-bf280a65b8db,"cali-fw",8:(tun0)]: Data: Internal Gateway: 10.8.1.1
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.1505] vpn-connection[0x5622aa56c370,ae3693ea-df59-414e-95a8-bf280a65b8db,"cali-fw",8:(tun0)]: Data: Internal Address: 10.8.1.2
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.1505] vpn-connection[0x5622aa56c370,ae3693ea-df59-414e-95a8-bf280a65b8db,"cali-fw",8:(tun0)]: Data: Internal Prefix: 24
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.1505] vpn-connection[0x5622aa56c370,ae3693ea-df59-414e-95a8-bf280a65b8db,"cali-fw",8:(tun0)]: Data: Internal Point-to-Point Address: 10.8.1.2
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.1505] vpn-connection[0x5622aa56c370,ae3693ea-df59-414e-95a8-bf280a65b8db,"cali-fw",8:(tun0)]: Data: Maximum Segment Size (MSS): 0
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.1505] vpn-connection[0x5622aa56c370,ae3693ea-df59-414e-95a8-bf280a65b8db,"cali-fw",8:(tun0)]: Data: Static Route: 192.168.0.0/24 Next Hop: 10.8.1.1
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.1506] vpn-connection[0x5622aa56c370,ae3693ea-df59-414e-95a8-bf280a65b8db,"cali-fw",8:(tun0)]: Data: Forbid Default Route: yes
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.1506] vpn-connection[0x5622aa56c370,ae3693ea-df59-414e-95a8-bf280a65b8db,"cali-fw",8:(tun0)]: Data: Internal DNS: 192.168.0.2
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.1506] vpn-connection[0x5622aa56c370,ae3693ea-df59-414e-95a8-bf280a65b8db,"cali-fw",8:(tun0)]: Data: DNS Domain: 'ozone.caligrafix.cl'
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.1506] vpn-connection[0x5622aa56c370,ae3693ea-df59-414e-95a8-bf280a65b8db,"cali-fw",8:(tun0)]: Data: No IPv6 configuration
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.1506] vpn-connection[0x5622aa56c370,ae3693ea-df59-414e-95a8-bf280a65b8db,"cali-fw",8:(tun0)]: VPN plugin: state changed: started (4)
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.1576] vpn-connection[0x5622aa56c370,ae3693ea-df59-414e-95a8-bf280a65b8db,"cali-fw",8:(tun0)]: VPN connection: (IP Config Get) complete
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.1578] device (tun0): state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41]
Feb 18 11:56:37 tadzim3 nm-dispatcher: req:3 'vpn-up' [tun0]: new request (2 scripts)
Feb 18 11:56:37 tadzim3 nm-dispatcher: req:3 'vpn-up' [tun0]: start running ordered scripts...
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.1806] keyfile: add connection in-memory (9d0256dc-d1cf-4bb1-9f5d-928b94598bc5,"tun0")
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.1819] device (tun0): state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41]
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.1833] device (tun0): Activation: starting connection 'tun0' (9d0256dc-d1cf-4bb1-9f5d-928b94598bc5)
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.2150] device (tun0): state change: disconnected -> prepare (reason 'none') [30 40 0]
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.2159] device (tun0): state change: prepare -> config (reason 'none') [40 50 0]
Feb 18 11:56:37 tadzim3 systemd-resolved[2865]: Switching to DNS server 192.168.0.2 for interface tun0.
Feb 18 11:56:37 tadzim3 systemd-resolved[2865]: Processing query...
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.2167] device (tun0): state change: config -> ip-config (reason 'none') [50 70 0]
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.2169] device (tun0): state change: ip-config -> ip-check (reason 'none') [70 80 0]
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.2175] device (tun0): state change: ip-check -> secondaries (reason 'none') [80 90 0]
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.2178] device (tun0): state change: secondaries -> activated (reason 'none') [90 100 0]
Feb 18 11:56:37 tadzim3 NetworkManager[2242]: <info> [1487429797.2366] device (tun0): Activation: successful, device activated.
Feb 18 11:56:37 tadzim3 nm-dispatcher: req:4 'up' [tun0]: new request (2 scripts)
Feb 18 11:56:38 tadzim3 ntpd[6182]: Listen normally on 8 tun0 10.8.1.2:123
Feb 18 11:56:38 tadzim3 ntpd[6182]: Listen normally on 9 tun0 [fe80::9e47:bfa7:d9ad:d85e%8]:123
Feb 18 11:56:38 tadzim3 ntpd[6182]: new interface(s) found: waking up resolver
Feb 18 11:56:42 tadzim3 systemd-resolved[2865]: Processing query...
Feb 18 11:56:47 tadzim3 systemd[1]: Stopping LSB: Start NTP daemon...
Feb 18 11:56:47 tadzim3 systemd[1]: Reloading OpenBSD Secure Shell server.
Feb 18 11:56:47 tadzim3 systemd[1]: Reloaded OpenBSD Secure Shell server.
Feb 18 11:56:47 tadzim3 ntp[7276]: * Stopping NTP server ntpd
Feb 18 11:56:47 tadzim3 ntp[7276]: ...done.
Feb 18 11:56:47 tadzim3 systemd[1]: Stopped LSB: Start NTP daemon.
Feb 18 11:56:47 tadzim3 systemd[1]: Reloading.
Feb 18 11:56:47 tadzim3 systemd[1]: Configuration file /etc/systemd/system/postfix.service.d/override.conf is marked world-inaccessible. This has no effect as configuration data is accessible via APIs without restrictions. Proceeding anyway.
Feb 18 11:56:47 tadzim3 systemd[1]: apt-daily.timer: Adding 2h 9min 1.281280s random time.
Feb 18 11:56:47 tadzim3 nm-dispatcher: req:4 'up' [tun0]: start running ordered scripts...
Feb 18 11:56:47 tadzim3 systemd-resolved[2865]: Processing query...

ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: dnsmasq (not installed)
ProcVersionSignature: Ubuntu 4.9.0-15.16-generic 4.9.5
Uname: Linux 4.9.0-15-generic x86_64
ApportVersion: 2.20.4-0ubuntu2
Architecture: amd64
CurrentDesktop: GNOME
Date: Sat Feb 18 11:58:07 2017
InstallationDate: Installed on 2015-01-23 (756 days ago)
InstallationMedia: Ubuntu-GNOME 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2)
SourcePackage: dnsmasq
UpgradeStatus: Upgraded to zesty on 2017-01-23 (25 days ago)

[Joshua Powers (powersj)]

Thank you for taking the time to file a bug report.

Since there is not enough information in your report to begin triage or to
differentiate between a local configuration problem and a bug in Ubuntu, I
am marking this bug as "Incomplete". We would be grateful if you would:
provide a more complete description of the problem, explain why you
believe this is a bug in Ubuntu rather than a problem specific to your
system, and then change the bug status back to "New".

For local configuration issues, you can find assistance here:
http://www.ubuntu.com/support/community

[gpothier (gpothier)]

Hi:
Regarding why I believe this is a bug in Ubuntu: it used to work, and stopped working after an update, without any configuration change on my part. Besides, there has been some flux in the resolvconf/dnsmasq systems, see for instance https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1642973, which seems to have been solved. That's why I filed a separate report for this issue.

As for a more complete description:
The VPN is using OpenVPN, with PFSense as a server.
I am using split DNS (check the "use this connection only for resources on its network" flag)

[Launchpad Janitor (janitor)]

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

[Jeroen Hoek (mail-jeroenhoek)]

I am running into DNS issues with OpenVPN as well. When connected `dig ddg.gg` fails, but `dig ddg.gg @8.8.8.8` works. This started after running updates yesterday.

I can't tell if bug #1667825 is the same issue, but I get the same problem regardless of whether I start OpenVPN from the command line or via the Network-Manager. (I'm not sure if the latter makes the connection 'managed' or not.)

Can this issue be scaled up in importance if confirmed? Users not being able to use a VPN service (e.g., in a place with free public wifi) is a huge security risk!