After connecting to OpenVPN server the default DNS is no longer available

Bug #1304437 reported by Michal Sylwester
56
This bug affects 11 people
Affects Status Importance Assigned to Milestone
network-manager-openvpn (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

After connecting to OpenVPN server Network Manager reconfigures dnsmasq to use DNS server provided by OpenVPN server for remote domains. On new trusty install this also removes the previously configured default DNS entry:

syslog fragment from saucy system (skipped unrelated parts):
Apr 8 22:26:50 msylw-imac NetworkManager[1365]: <info> Forbid Default Route: yes
Apr 8 22:26:50 msylw-imac NetworkManager[1365]: <info> Internal DNS: 10.68.0.1
Apr 8 22:26:50 msylw-imac NetworkManager[1365]: <info> DNS Domain: 'openvpn'
Apr 8 22:26:50 msylw-imac NetworkManager[1365]: <info> No IPv6 configuration
Apr 8 22:26:50 msylw-imac dnsmasq[2932]: reading /etc/resolv.conf
Apr 8 22:26:50 msylw-imac dnsmasq[2932]: using nameserver 127.0.1.1#53
Apr 8 22:26:50 msylw-imac dnsmasq[2932]: using local addresses only for unqualified names
Apr 8 22:26:51 msylw-imac whoopsie[1431]: online
Apr 8 22:26:51 msylw-imac NetworkManager[1365]: <info> VPN connection 'OpenVPN' (IP Config Get) complete.
Apr 8 22:26:51 msylw-imac NetworkManager[1365]: <info> Policy set 'fake mac' (eth0) as default for IPv4 routing and DNS.
Apr 8 22:26:51 msylw-imac NetworkManager[1365]: <info> Writing DNS information to /sbin/resolvconf
Apr 8 22:26:51 msylw-imac dnsmasq[1936]: setting upstream servers from DBus
Apr 8 22:26:51 msylw-imac dnsmasq[1936]: using nameserver 10.68.0.1#53 for domain 10.in-addr.arpa
Apr 8 22:26:51 msylw-imac dnsmasq[1936]: using nameserver 10.68.0.1#53 for domain openvpn
Apr 8 22:26:51 msylw-imac dnsmasq[1936]: using nameserver xxx.xxx.xxx.xxx#53

syslog fragment from saucy system (skipped unrelated parts):
Apr 8 22:20:15 msylw-air NetworkManager[899]: <info> Forbid Default Route: yes
Apr 8 22:20:15 msylw-air NetworkManager[899]: <info> Internal DNS: 10.68.0.1
Apr 8 22:20:15 msylw-air NetworkManager[899]: <info> DNS Domain: 'openvpn'
Apr 8 22:20:15 msylw-air NetworkManager[899]: <info> IPv6 configuration:
Apr 8 22:20:15 msylw-air NetworkManager[899]: <info> Internal Address: fd90:2810:5452::1001
Apr 8 22:20:15 msylw-air NetworkManager[899]: <info> Internal Prefix: 64
Apr 8 22:20:15 msylw-air NetworkManager[899]: <info> Internal Point-to-Point Address: fd90:2810:5452::1
Apr 8 22:20:15 msylw-air NetworkManager[899]: <info> Maximum Segment Size (MSS): 0
Apr 8 22:20:15 msylw-air NetworkManager[899]: <info> Forbid Default Route: no
Apr 8 22:20:15 msylw-air NetworkManager[899]: <info> DNS Domain: 'openvpn'
Apr 8 22:20:15 msylw-air nm-openvpn[5055]: Initialization Sequence Completed
Apr 8 22:20:17 msylw-air NetworkManager[899]: <info> VPN connection 'Hokudai' (IP Config Get) complete.
Apr 8 22:20:17 msylw-air NetworkManager[899]: <info> Policy set 'wifi' (wlan0) as default for IPv4 routing and DNS.
Apr 8 22:20:17 msylw-air NetworkManager[899]: <info> Policy set 'OpenVPN' (tun0) as default for IPv6 routing and DNS.
Apr 8 22:20:17 msylw-air NetworkManager[899]: <info> Writing DNS information to /sbin/resolvconf
Apr 8 22:20:17 msylw-air dnsmasq[1943]: setting upstream servers from DBus
Apr 8 22:20:17 msylw-air dnsmasq[1943]: using nameserver 10.68.0.1#53 for domain 10.in-addr.arpa
Apr 8 22:20:17 msylw-air dnsmasq[1943]: using nameserver 10.68.0.1#53 for domain openvpn

Note no last entry for default nameserver. As for me the DNS server provided by OpenVPN serves only local addresses this breaks internet connectivity.

Revision history for this message
Michal Sylwester (msylwester) wrote :

2 more observations:
- After upgrading saucy to trusty: I have the same problem
- Downgrading network-manager-openvpn to saucy version (0.9.8.2-1ubuntu2) fixed the problem.

It seems that the IPv6 patches somehow broke IPv4 for me, but I wasn't able to figure out why...

Revision history for this message
Michal Sylwester (msylwester) wrote :

One more comment: I had a leftover IPv6 config on the server, which basically ment it was enabled but not really used. After disabling it (commenting out all "server-ipv6") everything works as it used to, just without IPv6.

I've noticed now what I missed before, in syslog (again, parts removed):
Apr 18 09:42:10 msylw-imac NetworkManager[1152]: <info> IPv4 configuration:
Apr 18 09:42:10 msylw-imac NetworkManager[1152]: <info> Forbid Default Route: yes
Apr 18 09:42:10 msylw-imac NetworkManager[1152]: <info> IPv6 configuration:
Apr 18 09:42:10 msylw-imac NetworkManager[1152]: <info> Forbid Default Route: no

My guess is that the ipv6 config also prevented the "old" default dns from being used for ipv4.
I have no idea whether it makes sense to have forbid default route for ipv4 but not for ipv6, and whether this should stay here or be considered configuration error.

BTW: I'm currently using kubuntu, and it lacks the dialog for configuring ipv6 for openvpn. If this would be considered invalid configuration then perhaps this has to be redirected as gui problem.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in network-manager-openvpn (Ubuntu):
status: New → Confirmed
Revision history for this message
Thiago Martins (martinx) wrote :

I'm facing this problem too...

And one more... The `network-manager-openvpn` on Trusty is replacing the "default route" of my Ubuntu Desktop to the VPN tunnel! This way, I am unable to browse the Internet after stablishing the OpenVPN connection through NetworkManager...

No idea about how to change this behavior... Tips?!

Tks!
Thiago

Revision history for this message
Thiago Martins (martinx) wrote :

Guys,

Please, ignore my latest message, I just enabled the option:

Edit "VPN Connection 1" -> "IPv4 Settings" -> Routes... -> "[X] Use this connection only for resources on this network".

Sorry about the buzz...

Revision history for this message
Leonid Evdokimov (darkk) wrote :

I faced same issue.

My setup is:
IPv4 [+] use this connection only for resources on its network
IPv6 [-] use this connection only for resources on its network

I get `REFUSED` when I try to run `dig google.com.` and I see following at /var/log/syslog:

May 12 21:54:45 localhost NetworkManager[19137]: <info> Writing DNS information to /sbin/resolvconf
May 12 21:54:45 localhost dnsmasq[19070]: setting upstream servers from DBus
...
May 12 21:54:45 localhost dnsmasq[19070]: using nameserver 213.180.205.1#53 for domain yandex.net
May 12 21:54:45 localhost NetworkManager[19137]: <info> VPN plugin state changed: started (4)

When I change setup to:
IPv4 [+] use this connection only for resources on its network
IPv6 [+] use this connection only for resources on its network

I can resolve non-VPN domain names and non-specific nameserver is mentioned at the /var/log/syslog too:

May 12 21:58:20 localhost dnsmasq[19070]: setting upstream servers from DBus
...
May 12 21:58:20 localhost dnsmasq[19070]: using nameserver 213.180.205.1#53 for domain yandex.net
May 12 21:58:20 localhost dnsmasq[19070]: using nameserver 192.168.42.1#53 <---- that one :)
May 12 21:58:20 localhost dbus[840]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)

Revision history for this message
Phil Weir (phil-weir) wrote :

For me, this seems to have been a case of VPN server misconfiguration going unnoticed until the recent fixes. Just in case you're in a position where somebody else is responsible for the server, or there's a different etiology, checking
  IPv6 [+] use this connection only for resources on its network
(as suggested by darkk) also works for me.

Revision history for this message
Jason Gunthorpe (jgunthorpe) wrote :

This still happens in Xenial.

#7 has it right, if the IPv4 and IPv6 'use this connection only for resources on its network' are different then the default DNS server is dropped.

It is very easy to make this mistake and very hard to figure out that is the problem!

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.