network-manager suddenly using VPN nameserver for single domain only, not updating resolv.conf

Bug #1440607 reported by Trent Lloyd
30
This bug affects 5 people
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

When connecting to a VPN using network manager (openconnect), DNS resolution stops working for me.

This is a regression since 14.10 (and vivid in the last few weeks) where it worked as before. Verified working on a fresh install of 14.10, upgraded and then verified broken on 15.04.

Under 14.10 (utopic), the VPN name-servers were used for the entire system.

Under 15.04 (vivid), as of this week, it uses the VPN name-servers only for the "VPN domain" (in this case, au.wordomain.com) and attempts to use the LAN name-server for all other names.

This breaks for two reasons

 (1) The VPN domain (which is automatically retrieved from the VPN server, and is not manually set, and cannot be overridden) is not the only domain I required overridden to get internal DNS.

 (2) The local nameserver access is blocked/firewalled by the openconnect policy, and thus even global resolution stops workling.

NetworkManager[836]: <info> VPN connection 'Work VPN' (IP Config Get) reply received.
NetworkManager[836]: <info> VPN connection 'Work VPN' (IP4 Config Get) reply received.
NetworkManager[836]: <info> VPN connection 'Work VPN' (IP6 Config Get) reply received.
NetworkManager[836]: <info> VPN Gateway: 101.10.10.101
NetworkManager[836]: <info> Tunnel Device: vpn0
NetworkManager[836]: <info> IPv4 configuration:
NetworkManager[836]: <info> Internal Address: 10.131.11.21
NetworkManager[836]: <info> Internal Prefix: 21
NetworkManager[836]: <info> Internal Point-to-Point Address: 10.131.11.21
NetworkManager[836]: <info> Maximum Segment Size (MSS): 0
NetworkManager[836]: <info> Forbid Default Route: no
NetworkManager[836]: <info> Internal DNS: 10.97.11.12
NetworkManager[836]: <info> Internal DNS: 10.97.12.12
NetworkManager[836]: <info> DNS Domain: 'au.workdomain.com'
NetworkManager[836]: <info> IPv6 configuration:
NetworkManager[836]: <info> Internal Address: 2406:cdef:abc:dead:beef::13
NetworkManager[836]: <info> Internal Prefix: 64
NetworkManager[836]: <info> Internal Point-to-Point Address: 2406:cdef:abc:dead:beef::13
NetworkManager[836]: <info> Maximum Segment Size (MSS): 0
NetworkManager[836]: <info> Forbid Default Route: no
NetworkManager[836]: <info> DNS Domain: 'au.workdomain.com'
openconnect[2710]: Connected vpn0 as 10.131.11.21 + 2406:cdef:abc:dead:beef::13/64, using SSL
NetworkManager[836]: <info> (vpn0): link connected
NetworkManager[836]: <info> VPN connection 'Work VPN' (IP Config Get) complete.
NetworkManager[836]: <info> VPN plugin state changed: started (4)
NetworkManager[836]: <info> NetworkManager state is now CONNECTED_LOCAL
NetworkManager[836]: <info> NetworkManager state is now CONNECTED_GLOBAL
NetworkManager[836]: <info> Policy set 'Work VPN' (vpn0) as default for IPv6 routing and DNS.
NetworkManager[836]: <info> Writing DNS information to /sbin/resolvconf
dnsmasq[1485]: setting upstream servers from DBus
dnsmasq[1485]: using nameserver 220.233.0.4#53
dnsmasq[1485]: using nameserver 220.233.0.3#53
dnsmasq[1485]: using nameserver 10.101.11.12#53 for domain au.workdomain.com
dnsmasq[1485]: using nameserver 10.101.11.12#53 for domain 10.in-addr.arpa
dnsmasq[1485]: using nameserver 10.101.12.12#53 for domain au.workdomain.com
dnsmasq[1485]: using nameserver 10.101.12.12#53 for domain 10.in-addr.arpa

Revision history for this message
Trent Lloyd (lathiat) wrote :

Same connection a couple weeks ago:
Mar 25 08:54:23 localhost NetworkManager[809]: <info> VPN connection 'Work VPN' (IP Config Get) reply received.
Mar 25 08:54:23 localhost NetworkManager[809]: <info> VPN connection 'Work VPN' (IP4 Config Get) reply received.
Mar 25 08:54:23 localhost NetworkManager[809]: <info> VPN Gateway: 101.10.10.101
Mar 25 08:54:23 localhost NetworkManager[809]: <info> Tunnel Device: vpn0
Mar 25 08:54:23 localhost NetworkManager[809]: <info> IPv4 configuration:
Mar 25 08:54:23 localhost NetworkManager[809]: <info> Internal Address: 10.131.11.21
Mar 25 08:54:23 localhost NetworkManager[809]: <info> Internal Prefix: 21
Mar 25 08:54:23 localhost NetworkManager[809]: <info> Internal Point-to-Point Address: 10.131.11.21
Mar 25 08:54:23 localhost NetworkManager[809]: <info> Maximum Segment Size (MSS): 0
Mar 25 08:54:23 localhost NetworkManager[809]: <info> Forbid Default Route: no
Mar 25 08:54:23 localhost NetworkManager[809]: <info> Internal DNS: 10.97.11.12
Mar 25 08:54:23 localhost NetworkManager[809]: <info> Internal DNS: 10.97.12.12
Mar 25 08:54:23 localhost NetworkManager[809]: <info> DNS Domain: 'au.workdomain.com'
Mar 25 08:54:23 localhost NetworkManager[809]: <info> No IPv6 configuration
Mar 25 08:54:23 localhost NetworkManager[809]: <info> (vpn0): link connected
Mar 25 08:54:23 localhost openconnect[22503]: Connected vpn0 as 10.131.11.21, using SSL
Mar 25 08:54:23 localhost NetworkManager[809]: <info> VPN connection 'Work VPN' (IP Config Get) complete.
Mar 25 08:54:23 localhost NetworkManager[809]: <info> VPN plugin state changed: started (4)
Mar 25 08:54:23 localhost NetworkManager[809]: <info> NetworkManager state is now CONNECTED_LOCAL
Mar 25 08:54:23 localhost NetworkManager[809]: <info> NetworkManager state is now CONNECTED_GLOBAL
Mar 25 08:54:23 localhost NetworkManager[809]: <info> Writing DNS information to /sbin/resolvconf
Mar 25 08:54:23 localhost dnsmasq[1454]: setting upstream servers from DBus
Mar 25 08:54:23 localhost dnsmasq[1454]: using nameserver 10.97.11.12#53
Mar 25 08:54:23 localhost dnsmasq[1454]: using nameserver 10.101.11.12#53

Revision history for this message
Trent Lloyd (lathiat) wrote :

Created a fresh 14.10 installation (utopic) + network-manager-openconnect-gnome and confirmed the original behaviour.
Upgraded same installation to 15.04 and now experiencing the same behaviour as reported above.

Additionally, as this VPN specifies that other traffic is firewalled, the default local nameserver does not function and so DNS breaks entirely once connected.

Trent Lloyd (lathiat)
description: updated
Revision history for this message
Trent Lloyd (lathiat) wrote :

Further investigation:
 - Disabling dns=dnsmasq handler means this does not occur
 - I am ending up with VPN_IP4_DOMAINS set in the log
 - Default route is getting set to the vpn, and is configured as such (the 'disable default route' is not selected)
 - Reading debian/patches/dnsmasq-vpn-dns-filtering.patch, it implies that if the default route is not disabled then it shouldn't try and split horizon DNS in the first place.

Attaching debug network manager output.. not yet clear at exactly which stage the decision to do split DNS is being made.

Revision history for this message
Trent Lloyd (lathiat) wrote :
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
Barry Warsaw (barry) wrote :

I think this is the bug I'm seeing too on Xenial now. Even though I have "Use this connection only for resources on its network" enabled for both IPv4 and IPv6, once the VPN is brought up, all DNS for my LAN (i.e. talking to my internal DNS server) is non-functional and my internal LAN host names are not resolvable.

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.