Unable to resolve VPN names AND connect to the Internet

[Eeqmcsq]

Binary package hint: network-manager-vpnc

1) I am running Ubuntu Jaunty 9.04 (upgraded from Ubuntu Intrepid 8.10)
2) Version for network-manager-vpnc: 0.7.1~rc4.20090316+bzr21-0ubuntu2
3) When I use VPN on my home PC to connect to my work LAN, I expected to be able to resolve my work PC's name and surf the Internet normally. This was the existing behavior in Intrepid 8.10.
4) When I connect to my work LAN via VPN, my home PC could not simultaneously surf the Internet. I could resolve my work PC's name and I could ping my work PC's IP address.

I found a solution where I should edit my VPN connection -> IPv4 Settings tab -> Routes -> check "Use this connection only for resources on its network". When I did so, I was able to surf the Internet, but I could NOT resolve my work PC's name. Pinging my work PC's IP address was still OK. Summary:

"Use this connection only for resources on its network" is unchecked:
- nslookup my_work_pc (this took a few moments, but it correctly returned my work pc's IP)
- ping my.work.pc.IP (this worked correctly)
- ping 74.125.127.99 (this is google's IP address. this FAILED)

"Use this connection only for resources on its network" is checked:
- nslookup my_work_pc (this FAILED. ** server can't find my_work_pc)
- ping my.work.pc.IP (this worked correctly)
- ping 74.125.127.99 (this worked correctly)

Other info:
- My vpn type is "Cisco Compatible VPN (vpnc)"

[Mathieu Trudel-Lapierre (cyphermox)]

Hi, thanks for reporting this bug and helping improve Ubuntu and NetworkManager. Unfortunately, we cannot start looking into this bug as there is not enough information.

Could you provide us with the contents of /etc/resolv.conf as well as the output of the 'netstat -rn' command when connected to the VPN with the "Use this connection only for resources on its network" option checked, as well as the same data for when you connect to the VPN with the "Use this connection only for resources on its network" option unchecked. Thanks!

[Eeqmcsq (lelandyue)]

Since the results were long, I have attached the results in a .txt file. The only modification I made to the results was to edit out my work company's name and used "my.work-domain.com". Otherwise, the results were copied directly from the console output to the .txt file.

In analyzing the results, the output of /etc/resolv.conf was identical. The output of netstat -rn was identical, EXCEPT for the last line:

"Use this connection only for resources on its network" is unchecked:

Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0

"Use this connection only for resources on its network" is checked:

Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth1

Other notes:
- eth1 is my gigabit network card. My eth0 is an integrated 10/100, which I have disabled in the BIOS.

[Mathieu Trudel-Lapierre (cyphermox)]

This is likely due to the fact that my.work-domain.com is resolvable both by 68.94.156.1 and 68.94.157.1, as well as 192.168.101.5 but contain different entries depending on the fact that the request is "from the internet" or "from the VPN".

Could you please try to set your VPN connection to "IP address only" under IPv4 Parameters, and enter your DNS server's IP address and domain to search through, and let us know if it works better? Please keep "Use this connection only for resources on its network" checked for your test.

Thanks,

[Eeqmcsq (lelandyue)]

Since using "my.work-domain.com" would be vague and confusing, I have decided not to hide the actual domain. That way, you will be able to run tests of your own. The original domain name is svl.access-company.com. I will continue to hide my work PC name and IP address.

> my.work-domain.com is resolvable both by 68.94.156.1 and 68.94.157.1
It turns out that svl.access-company.com is NOT resolvable by these two. I can prove this by trying to resolve svl.access-company.com when disconnected from VPN.

** server can't find svl.access-company.com: NXDOMAIN

Hmm... if the sbcglobal.net DNS servers failed to resolve svl.access-company.com, I wonder why Ubuntu didn't try my work DNS next. Had Ubuntu tried my work DNS server next, it would have resolved correctly.

> and enter your DNS server's IP address and domain to search through
I presume you mean for me to enter my work DNS server's IP address and my work domain. I have attached the results of this test. The results are the same: I still cannot resolve my work PC by name.

After understanding that this is a DNS name resolution problem, I decided to conduct my own test. I connected to my work VPN, then manually edited /etc/resolv.conf and moved my work DNS ABOVE the sbcglobal.net DNS servers. The results were that everything worked exactly as they did in Ubuntu 8.10. I could connect to my work PC and I could surf the Internet. So hope that helps. The results are also in the same attached file.

[Mathieu Trudel-Lapierre (cyphermox)]

Eeqmcsq,

Sorry for the delay in getting back to you on this.

AFAIK, the DNS resolver would have continued on to the next DNS server, *unless* the first answered with NXDOMAIN, which is likely the case when you try to ask for DNS information on a domain that is available both from the Internet and locally, but most likely not with the same information (because of DNS views)

This doesn't look like a bug but just to be sure, please do your above test again -- from what I can see from here, ns1.sbcglobal.net seems to find svl.access-company.com just fine, although it full probably not have your machine as an entry in the zone unless you are connected to the VPN (if there indeed should be your_machine.svl.access-company.com). Let me know of the results...

[Eeqmcsq (lelandyue)]

Without connecting via VPN, my work domain "svl.access-company.com" is still not resolvable by the sbcglobal's DNS servers. And yes, they are returning NXDOMAIN.

~$ nslookup svl.access-company.com
Server: 68.94.156.1
Address: 68.94.156.1#53

** server can't find svl.access-company.com: NXDOMAIN

============
But what I don't understand is why this all worked in 8.10 and not 9.04. So I fired up an ubuntu64 8.10 live CD I had lying around and created my work VPN connection. After a few tests, I see that the difference is in /etc/resolv.conf. See the attached file for the results.

So I think the cause of my original bug is that in 9.04, my work DNS servers were placed AFTER my sbcglobal.net DNS servers, whereas in 8.10, they were placed BEFORE my sbcglobal.net DNS servers. Also, I don't understand why there is now a differently formatted resolv.conf on my ubuntu64 PC. Any ideas?

[Mathieu Trudel-Lapierre (cyphermox)]

I realise that it's not likely the case, but please take a look at your wired or wireless connection and ensure you haven't set DNS servers somewhere (in settings in resolvconf (somewhere under /etc/resolvconf), and in the network-manager connection configuration dialogs).

I'll build a virtual machine with Jaunty in 64 bit and try to reproduce the problem...

/ Matt

[Eeqmcsq (lelandyue)]

System -> Preferences -> Network Connections -> VPN tab -> Edit (my VPN connection) -> IPv4 Settings tab. The Method is set to Automatic (VPN). The DNS Servers and Search Domains are empty (and disabled anyway).

When I am NOT connected via VPN:
$ grep -R 192 /etc/resolvconf/
<No results found>

When I am connected via VPN:
$ grep -R 192 /etc/resolvconf/
/etc/resolvconf/run/interface/NetworkManager:nameserver 192.168.101.5
/etc/resolvconf/run/interface/NetworkManager:nameserver 192.168.101.11
/etc/resolvconf/run/resolv.conf:nameserver 192.168.101.5

================================================
I think I figured out what the difference is between my Jaunty32 (which puts my work DNS below my ISP DNS) and my Jaunty64 (which puts my work DNS above my ISP DNS).

On my Jaunty64, my /etc/resolv.conf is an actual text file.

On my Jaunty32, my /etc/resolv.conf turned out to be a symlink to /etc/resolvconf/run/resolv.conf.

When I renamed my /etc/resolv.conf to a different name (/etc/resolv.conf.symlink) and rebooted, a new /etc/resolv.conf text file was generated. This text file has the same formatting as the resolv.conf on my Jaunty64:
# Generated by NetworkManager

instead of:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)

Furthermore, when I am connected via VPN, my work DNS servers are now correctly placed above my ISP DNS, so I can both connect to my work PC by computer name, AND surf the Internet at the same time.

================================================
To summarize my entire fix:

1. System -> Preferences -> Network Connections -> VPN tab -> Edit (my VPN connection) -> IPv4 Settings tab -> Routes
Make sure "Use this connection only for resources on its network" is checked.
2. Determine if resolv.conf is a symlink. If it is NOT a symlink, then the problem may be something else.
file /etc/resolv.conf
3. If it is a symlink to `/etc/resolvconf/run/resolv.conf', rename it to something else:
sudo mv /etc/resolv.conf /etc/resolv.conf.symlink
4. Reboot.
5. Test and see if you can surf the Internet and connect to your VPN PCs.
6. If test was successful, you can delete /etc/resolv.conf.symlink:
sudo rm /etc/resolv.conf.symlink

[Launchpad Janitor (janitor)]

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

[Joseph Garvin (k04jg02)]

Gah, I switched this from "expired" by accident (have a similar but different problem) and launchpad doesn't give me the option to change it back. Feel free to revert :p

[David Harper (inquisitivedave)]

Hi,

Just updated to clean Natty Beta and am coming across this issue. Was working for me fine previously. More than willing to provide files and traces if you tell me what you want.

Thanks,

[David Harper (inquisitivedave)]

Following some of the steps above, when connected to my domain via VPN, resolv.conf has:

domain my-domain.com
search my-domain.com google.com
nameserver [my-dns-ip]
nameserver 8.8.8.8
nameserver 8.8.4.4

and I also have the "Routes - Only traffic" box ticked. Under this configuration, the outside world loads fine, but stuff on my-domain just hangs whilst looking it up.

resolve.conf is very much a file and not a symlink.

Natty x64

[Mathieu Trudel-Lapierre (cyphermox)]

Unfortunately, this appears to be expected and wanted behavior. The reason for this is that you can only go two different ways: either the VPN's nameserver is set *above* the local nameserver so that VPN connections will work automatically once connected to (the issue the original reporter was referring to as not working, which apparently should be fixed in releases after Jaunty (and IIRC fixed in Lucid for sure)), or set the VPNs nameservers after local nameservers, which makes internet access work fine even through a VPN, but causes issues if the domain in use is resolvable with both types of nameservers.

There is no way to please everybody unless using DNS caching. This is planned for NM, but currently does not really have a roadmap that I know of.

In other words, Eeqmcsq, for your system to work as you expect you will need to upgrade to Lucid or later, so that you end up on NetworkManager 0.8 or later.

David, please file a separate bug for your issue and don't forget to attach resolv.conf as it is written on your system, as well as a snapshot of the routes applied when you are connected to the network. The exact domain name in use will also be required.