VPN connected but private-network names cannot be resolved; bypassing the local forwarding nameserver fixes it

[Paul Phillips]

1. Using Ubuntu 12.04 64bit
2. network-manager-vpnc 0.9.4.0-0ubuntu1
3. I expect that once connected to VPN, I should be able to access the servers within the private network.
4. The network manager reports that it has connected, however when I go to connect to the private servers, it fails
and a ping in the terminal returns "unknown host".

Upon further investigation and comparison with a working Ubuntu 11.10 system, I compared /etc/resolv.conf files.

The one that works had:
# Generated by NetworkManager
domain <domain>
search <domain>
nameserver <name server IP addr1>
nameserver <name server IP addr2>
nameserver <name server IP addr3>

Mine had:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search <domain>

[Paul Phillips (paul-gs-phillips)]

There does not appear to be any obvious work around.

[Mathieu Trudel-Lapierre (cyphermox)]

Can you please attach the file /run/nm-dns-dnsmasq.conf ?

Thanks!

[Paul Phillips (paul-gs-phillips)]

I have managed to get it working, but it's a hack:
Copy the good resolv.conf from the 11.10 working setup over the top of /run/resolvconf/resolv.conf
Now can connect to servers.

Will try to get a script to do this automatically on connection for convenience.

[Paul Phillips (paul-gs-phillips)]

See attached file. This is a hack workaround until the root cause is found. Copy this to
/etc/NetworkManager/dispatcher.d
Ensure that it is executable.

It also modified the MTU setting - which is required to access some servers inside the private network (e.g. sharepoint).
The script requires /etc/vpnc/resolv.conf.vpnc to exist. This is the corrected resolv.conf which will need to be sourced from a working vpnc setup.

[Mathieu Trudel-Lapierre (cyphermox)]

Are the settings in the nm-dns-dnsmasq.conf file correct? With this setup, only topcon.com names will be resolved over what I assume is the VPN; anything else would not be; and instead would fall through to being resolved with 192.168.1.254.

[David Hollinger III (eagledelta2)]

I can verify that I'm seeing this issue as well. I can connect, sets correct DNS servers, but I cannot connect to anything.

Can't connect to any of our inside servers, via DNS or IP, nor can I connect to internet locations via a web browser.

Syslog included (txt file)

[Paul Phillips (paul-gs-phillips)]

Hi Mathieu,

I'm not sure how to read nm-dns-dnsmasq.conf. The base IP address appears correct, but I don't understand what all the "in-addr.arpa" stuff is. There's also an IP address that appears in the resolv.conf, but not the dnsmasq.conf file.

Any other tests I can run to help?

Cheers,
Paul.

[Stephen Webb (webby69)]

Exact same problem here except I'm on 32-bit 12.04. I tried Kvpn with the same results. Since I don't have access to a working resolv.conf file I will probably have to go back to 11.10, it looks as if this bug is not going to be addressed, since it effects such a small number of people.

[Mathieu Trudel-Lapierre (cyphermox)]

David, if you can't connect by IP it's an issue with configuration, and very unlikely to be a bug (unless your vpn server is some brand new device that isn't supported).

Stephen, please file your own bug report. Using Kvpn is using a completely different method which will not be affected by the same bugs, but we can't know about them and fix them unless you file the bug reports for your own system, since everyone's configuration is different.

Paul, as per above, only subdomains of topcon.com will get resolved, are you using those names to try to reach the private servers?

The in-addr.arpa entries are there for reverse resolution, and generally not to be concerned with -- they will do the match from IP to name (instead of from name to IP to get to reach the systems).

You can try to ping and access servers by IP address, this should always be possible. If it's not, then there would be another thing that changed rather than DNS that affects your VPN connections.

As for the DNS; try to resolve hostnames under topcon.com normally; and again using "dig <domain name> @<the other nameserver from syslog that isn't listed in nm-dns-dnsmasq.conf>". Perhaps it's just that one of the DNS servers isn't responding properly.

While at it, could you please attach the output of 'ip route' ?

[tdeering (tomdeering7)]

This bug, as described, also affects me. VPN DNS resolution worked in 11.10, and was broken by changes made in 12.04.

[tdeering (tomdeering7)]

@Stephen The number of users affected is not as small as you may think. This bug is a duplicate of, or is related to, many other bugs filed about DNS resolution in 12.04.

 A quick Google search for "ubuntu 12.04 vpn dns" shows many disparate questions and answers about this topic. Unfortunately, I have yet to find a workaround to fix DNS over VPN, which worked out of the box in 11.10...

[Paul Phillips (paul-gs-phillips)]

Hi Mathieu,

I'm going from memory here - I think I tried using hostnames with the
topcon.com domain and without - both without success.
I didn't know the IP addresses so I couldn't try accessing them.

I can try ip route, but will have to wait - not in a position to try that
at present.

Did you mean me to try ip route with or without my "resolv.conf" fix?

Paul.

On 30 August 2012 00:23, Mathieu Trudel-Lapierre <email address hidden>wrote:

> David, if you can't connect by IP it's an issue with configuration, and
> very unlikely to be a bug (unless your vpn server is some brand new
> device that isn't supported).
>
> Stephen, please file your own bug report. Using Kvpn is using a
> completely different method which will not be affected by the same bugs,
> but we can't know about them and fix them unless you file the bug
> reports for your own system, since everyone's configuration is
> different.
>
> Paul, as per above, only subdomains of topcon.com will get resolved, are
> you using those names to try to reach the private servers?
>
> The in-addr.arpa entries are there for reverse resolution, and generally
> not to be concerned with -- they will do the match from IP to name
> (instead of from name to IP to get to reach the systems).
>
> You can try to ping and access servers by IP address, this should always
> be possible. If it's not, then there would be another thing that changed
> rather than DNS that affects your VPN connections.
>
> As for the DNS; try to resolve hostnames under topcon.com normally; and
> again using "dig <domain name> @<the other nameserver from syslog that
> isn't listed in nm-dns-dnsmasq.conf>". Perhaps it's just that one of the
> DNS servers isn't responding properly.
>
> While at it, could you please attach the output of 'ip route' ?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1013646
>
> Title:
> VPN network connects but cannot access servers
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/network-manager-vpnc/+bug/1013646/+subscriptions
>

[tdeering (tomdeering7)]

Confirmed: this issue persists in 12.10

[Thomas Hood (jdthood)]

Can this problem be worked around by disabling the local forwarding nameserver?

(Disable the local forwarding nameserver by commenting out the line "dns=dnsmasq" in /etc/NetworkManager/NetworkManager.conf.)

[Thomas Hood (jdthood)]

From the syslog

Jun 15 21:42:27 paul-Latitude-E6420 NetworkManager[1002]: <info> Internal IP4 DNS: 172.23.170.10
Jun 15 21:42:27 paul-Latitude-E6420 NetworkManager[1002]: <info> Internal IP4 DNS: 172.23.4.10
Jun 15 21:42:27 paul-Latitude-E6420 NetworkManager[1002]: <info> DNS Domain: 'topcon.com'
[...]
Jun 15 21:42:28 paul-Latitude-E6420 dnsmasq[4897]: using nameserver 192.168.1.254#53
Jun 15 21:42:28 paul-Latitude-E6420 dnsmasq[4897]: using nameserver 172.23.170.10#53 for domain 0.168.192.in-addr.arpa
Jun 15 21:42:28 paul-Latitude-E6420 dnsmasq[4897]: using nameserver 172.23.170.10#53 for domain 16.172.in-addr.arpa
Jun 15 21:42:28 paul-Latitude-E6420 dnsmasq[4897]: using nameserver 172.23.170.10#53 for domain 10.in-addr.arpa
Jun 15 21:42:28 paul-Latitude-E6420 dnsmasq[4897]: using nameserver 172.23.170.10#53 for domain 254.169.in-addr.arpa
Jun 15 21:42:28 paul-Latitude-E6420 dnsmasq[4897]: using nameserver 172.23.170.10#53 for domain 23.172.in-addr.arpa
Jun 15 21:42:28 paul-Latitude-E6420 dnsmasq[4897]: using nameserver 172.23.170.10#53 for domain topcon.com

Notice that only the first nameserver address is used. This is bug #1072899. As a result of this, if 172.23.170.10 is down 172.23.4.10 won't be tried.

Was the first nameserver nonresponsive when this report was originally filed? That along with bug #1072899 would explain the malfunction originally reported.

[Paul Phillips (paul-gs-phillips)]

Hi Thomas,

As it happens, I have the opportunity to try VPNing in today.
I did notice that I tried removing the resolv.conf workaround I've
mentioned earlier, and it connected ok, so perhaps your theory is correct!

I'll let you know if I find out anything else useful to report.

Thanks,
Paul.

On 29 January 2013 19:46, Thomas Hood <email address hidden> wrote:

> >From the syslog
>
> Jun 15 21:42:27 paul-Latitude-E6420 NetworkManager[1002]: <info> Internal
> IP4 DNS: 172.23.170.10
> Jun 15 21:42:27 paul-Latitude-E6420 NetworkManager[1002]: <info> Internal
> IP4 DNS: 172.23.4.10
> Jun 15 21:42:27 paul-Latitude-E6420 NetworkManager[1002]: <info> DNS
> Domain: 'topcon.com'
> [...]
> Jun 15 21:42:28 paul-Latitude-E6420 dnsmasq[4897]: using nameserver
> 192.168.1.254#53
> Jun 15 21:42:28 paul-Latitude-E6420 dnsmasq[4897]: using nameserver
> 172.23.170.10#53 for domain 0.168.192.in-addr.arpa
> Jun 15 21:42:28 paul-Latitude-E6420 dnsmasq[4897]: using nameserver
> 172.23.170.10#53 for domain 16.172.in-addr.arpa
> Jun 15 21:42:28 paul-Latitude-E6420 dnsmasq[4897]: using nameserver
> 172.23.170.10#53 for domain 10.in-addr.arpa
> Jun 15 21:42:28 paul-Latitude-E6420 dnsmasq[4897]: using nameserver
> 172.23.170.10#53 for domain 254.169.in-addr.arpa
> Jun 15 21:42:28 paul-Latitude-E6420 dnsmasq[4897]: using nameserver
> 172.23.170.10#53 for domain 23.172.in-addr.arpa
> Jun 15 21:42:28 paul-Latitude-E6420 dnsmasq[4897]: using nameserver
> 172.23.170.10#53 for domain topcon.com
>
> Notice that only the first nameserver address is used. This is bug
> #1072899. As a result of this, if 172.23.170.10 is down 172.23.4.10
> won't be tried.
>
> Was the first nameserver nonresponsive when this report was originally
> filed? That along with bug #1072899 would explain the malfunction
> originally reported.
>
> ** Changed in: network-manager-vpnc (Ubuntu)
> Status: Confirmed => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1013646
>
> Title:
> VPN connected but private-network names cannot be resolved; bypassing
> the local forwarding nameserver fixes it
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/network-manager-vpnc/+bug/1013646/+subscriptions
>

[Launchpad Janitor (janitor)]

[Expired for network-manager-vpnc (Ubuntu) because there has been no activity for 60 days.]

[Jo (16303-gmx)]

The problem is still presen in
Ubuntu 14.04 but can be cirumvented with the workaround mentioned by jdthood.

(Disable the local forwarding nameserver by commenting out the line "dns=dnsmasq" in /etc/NetworkManager/NetworkManager.conf.)

[Launchpad Janitor (janitor)]

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

[asala (asala)]

Updated from 16.04 to 16.10 yakkety yak... bug still present: I had to apply the workaround of commenting outdnsmasq mentioned in comments #16 and #20 to get vpn dns working. Such problem seems absent in a 16.04 box not yet updated to 16.10... and I don't remember having any issues on the first computer prior to the upgrade.

[zajc (zajcek)]

I have exactly the same problem as mentioned in the comment #22 after upgrading from 16.04 to 16.10. I commented out "dns=dnsmasq" in /etc/NetworkManager/NetworkManager.conf and now it is working.