VPN DNS only works for IP, not names

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

Just updated to 12.04 beta this. morning. VPN DNS resolving is broken.

Reverse resolving ip's works.
Resolving the name dont' works.

Workaround: If I disable the option option to use the vpn connection only for resources in the vpn network in the routing options, everything works.

My vpn pushes two search domains down. Only one is showing in /run/nm-dns-dnsmasq.conf. All the reverse dns entries are there.

jck's workaround from comment 5 does not work in my case. The first search domain is still there, the second is not.

Please provide full logs from /var/log/syslog after reproducing the problem.

The "use this connection" change really shouldn't be affecting much.

I can confirm this on n-m-vpnc as well; though it's unclear there yet whether the extra domains (in split-domain config on my Cisco ASA) are actually supported by vpnc. I'm adding a task to get this fixed.

Fixing this in openvpn should be feasible and probably simpler, since it probably just relies on the fact that the server misuses the domain field to pass more than one search domain. I don't know how the openconnect plugin deals with it.

Please, if you're getting this bug, we need to know more about what's going on and whether the extra domains are seen at all by the underlying application that deals with the vpn connection. That means we'll need debugging logs from the vpn service in use:

See http://live.gnome.org/NetworkManager/Debugging, scroll towards the end to the VPN plugin you use and attach the logs for it, after making sure they don't include sensitive data (be extra careful about passwords and such)

The domain is set to xxx.domain1.com (scrubbed name), domain2.com (also scrubbed) should also be set as a search domain, but it is not.

cat /run/nm-dns-dnsmasq.conf:
server=/xxx.domain1.com/192.168.42.11
server=/98.168.192.in-addr.arpa/192.168.42.11
server=/100.168.192.in-addr.arpa/192.168.42.11
server=/42.168.192.in-addr.arpa/192.168.42.11
server=192.168.1.1

There should also be an additional line like this:
server=/domain2.com/192.168.42.11

Right. Notice how you get only one of them in the debugging logs you've attached?

Mar 10 11:24:09 vicap-21299 NetworkManager[1025]: <info> DNS Domain: 'xxx.domain1.com'

In the suggested debugging howto (http://live.gnome.org/NetworkManager/Debugging) for your VPN, there should be another set of logs which we also need to ascertain that the extra domain is seen by the underlying application. That's where starting the nm-(vpn)-service binary comes in and is especially important. For example:

sudo /usr/lib/NetworkManager/nm-vpnc-service --debug
or
sudo /usr/lib/NetworkManager/nm-openvpn-service --debug

It's actually my fault for not specifying that the howto was missing information. Of course, you still need to make sure that that service application isn't running before you start it; then attach its output to this bug report.

I checked some non-debug log messages from before I upgraded to 12.04, and they only show the one domain, but resolution was working fine then. I tried getting the debug logs for the nm-openconnect-service, but they did not look useful. I will try again.

This is all I get:

~# /usr/lib/NetworkManager/nm-openconnect-service --debug

** WARNING **: property 'cookie-flags' unknown

** WARNING **: property 'certsigs-flags' unknown

** WARNING **: property 'autoconnect-flags' unknown

** WARNING **: property 'gateway-flags' unknown

** WARNING **: property 'gwcert-flags' unknown

** WARNING **: property 'xmlconfig-flags' unknown

** WARNING **: property 'lasthost-flags' unknown

** WARNING **: property 'certsigs' unknown

** WARNING **: property 'autoconnect' unknown

** WARNING **: property 'lasthost' unknown
** Message: openconnect started with pid 18392

In that last attachment, it works (I think) because the 42.11 name server was used first without being qualified by xxx.domain1.com, so it was used to resolve everything. (I think that it would fall back to the other servers if it could not resolve, but I know not how that magic works.)

It turns out that for my case, it was a misconfiguration on the VPN. Once the correct domain was set, resolution started working.

I experienced the same issue. After sucessfull OpenVPN connection /var/run/nm-dns-dnsmasq.conf contains the following:

server=/10.in-addr.arpa/10.1.106.7
server=192.168.0.1
server=192.168.3.2

This 10.in-addr.arpa prefix appears only when "Use this connection only for resources on its network" checkbox was turned on at IPV4 routes page of VPN configuration window. Syslog contains the following:
...
Mar 23 09:41:35 shakira dnsmasq[4138]: using nameserver 10.1.106.7#53 for domain 10.in-addr.arpa
...

Finally, I found, that the OpenVPN server was not pushing down the domain suffix. After inserting the proper "dhcp-option DOMAIN" entry into openvpn server configuration, it started to work.

openvpn server.conf:
...
push "dhcp-option DNS 10.1.106.7"
push "dhcp-option DOMAIN dev.xxx.domain.com"
...

/var/run/nm-dns-dnsmasq.conf:
...
server=/devzone.cloud.xemeti.com/10.1.106.7
...

So I think it is not a client side bug, just a server side configuration requirement. Affects only users with "Use this connection.." flag turned on, without dhcp-option DOMAIN push entry.

Hi Marton,

I can confirm this.
You can also configure the dns and searchdomain manually in the client, if you have no access to the vpn server.
After that, address resolution works vor names and ips again, even if the vpn is only used for adresses in the vpn network.

So closing this bug for both tasks as Invalid; since we're covering the vpnc issues separately in bug 954747.

Wow, it took me a while to find this post. For OpenVPN users specifically, there should be some sort of release note addition that explains that having the DNS push is no longer enough to have VPN dns resolution work.

i.e. Your OpenVPN DNS will no longer resolve resolve if you do not have the dhcp-option DOMAIN set server side, where it was working just fine on all other devices and previous versions of Ubuntu (leading users to believe it is a client-side issue).

And guess what; This server side tweak fixed a few mobile clients that use our VPN that would not get DNS resolution, likely using similar domain based routing like dnsmasq.

I can confirm this behavior:

- Connected with VPN, resolv.conf is proper
- Connected with network manager vpnc, resolv.conf does not update
- Connected using vpnc-connect command line updates resolv.conf properly

This is a big problem, as this affects "less experienced" users that are not confident fiddling around with config files and command lines...

The solution with pushing all domains is just not convenient, when accessing hundreds of domains through the VPN. Why having DNSMASQ on all hosts in the first place?