Ubuntu

vpnc issue with /etc/resolv.conf prevents connection

Reported by Sam Freer on 2008-11-13
28
This bug affects 4 people
Affects Status Importance Assigned to Milestone
network-manager-vpnc (Ubuntu)
Undecided
Unassigned
Nominated for Jaunty by Nicholas Christian Langkjær Ipsen
Nominated for Karmic by llamahunter
vpnc (Ubuntu)
Medium
Unassigned
Nominated for Jaunty by Nicholas Christian Langkjær Ipsen
Nominated for Karmic by llamahunter

Bug Description

Binary package hint: vpnc

vpnc 0.5.1r275-1ubunu1

This worked under Hardy but I can't get it working under Intrepid. The VPN connects successfully using VPNC but then I can't ping anything on the virtual network or connect using 'Terminal Services Client'.

I have a work around for the failure to connect using 'Terminal Services Client' after establishing a VPN connection via VPNC in 8.10.

Have a look at /etc/resolv.conf

Mine looks like this. It holds the DNS servers lookups.

# 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 192.168.1.254
search home

After I connect to my VPN it looks like this.

# 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 192.168.1.254
nameserver 10.66.5.40
nameserver 172.26.128.23
search home central.luton

If I try to ping a server on the VPN I get the following error.

ping: unknown host jewel

I then edit the file to comment out the original DNS entry.

sudo vi /etc/resolv.conf

# 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 192.168.1.254
nameserver 10.66.5.40
nameserver 172.26.128.23
search home central.luton

I can now ping the server on the VPN.

PING jewel.central.luton (10.66.9.50) 56(84) bytes of data.

Now I can also get a 'Terminal Services Client' session to connect.

I don't know if this is a bug and needs fixing but this works for now.

http://ubuntuforums.org/showthread.php?t=974092

Sam Freer (samfreer) wrote :

Here are my Hardy /etc/resolve.conf settings running under VirtualBox for comparison (this works)

Before VPN connection

Sam Freer (samfreer) wrote :

Here are my Hardy /etc/resolve.conf settings running under VirtualBox for comparison (this works)

Before VPN connection

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.2.0 * 255.255.255.0 U 0 0 0 eth0
link-local * 255.255.0.0 U 1000 0 0 eth0
default 10.0.2.2 0.0.0.0 UG 0 0 0 eth0

/etc/resolv.conf
### BEGIN INFO
#
# Modified_by: NetworkManager
# Process: /usr/bin/NetworkManager
# Process_id: 4191
#
### END INFO

search home

nameserver 10.0.2.3

After VPNC connection

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
86.12.88.3 10.0.2.2 255.255.255.255 UGH 0 0 0 eth0
10.0.2.0 * 255.255.255.0 U 0 0 0 eth0
link-local * 255.255.0.0 U 1000 0 0 eth0
default * 0.0.0.0 U 0 0 0 tun0

/etc/resolv.conf
### BEGIN INFO
#
# Modified_by: NetworkManager
# Process: /usr/bin/NetworkManager
# Process_id: 4191
#
### END INFO

search central.luton

nameserver 10.66.5.40

Hope this helps

John Doe (johndoe32102002) wrote :

I am having the same problem with Ubuntu Hardy and Ubuntu Intrepid (32-bit Intel) with KVPNC and VPNC.

One of the two programs fails to cleanup the dns /etc/resolv.conf back to its original state.

kvpnc --version
Qt: 3.3.8b
KDE: 3.5.10
kvpnc: 0.9.0

Here is the kvpnc.log:
error: The required daemon (vpnc) isn't available, connect will be disabled.
info: Import of "certificate" (PCF) was successful.
info: Profile "certificate" saved.
error: vpnc is too old. Minimum requirement is 0.3.x, disabling Xauth interactive option.
#sudo apt-get install vpnc
#Reading package lists... Done
#Building dependency tree
#Reading state information... Done
#vpnc is already the newest version. (on Intrepid)
error: The required daemon (vpnc) isn't available, connect will be disabled.
info: Saving profiles and global options...
info: Profile "certificate" saved.
info: Profiles saved.
info: Global options saved.
info: Gateway hostname (VPN_DNS_IP_#1) resolved to "SAME_IP".
info: Saving profiles and global options...
info: Profile "certificate" saved.
info: Profiles saved.
info: Global options saved.
debug: No default interface given, tried default interface, got success, using "eth1".
error: Tunnel device is missing, loading module "tun" has failed: stop.
debug: No default interface given, tried default interface, got success, using "eth1".
error: Tunnel device is missing, loading module "tun" has failed: stop.

Here is /etc/resolv.conf that fails to be cleaned up:
# 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 <VPN_DNS_SERVER_#1>
nameserver <VPN_DNS_SERVER_#2>
nameserver <MY_ROUTER_IP>
#Note: The VPN DNS servers are external ip addresses, that work on select domains, such as google, #but fail on some such as ubuntu.com). I have had to manually comment them out upon each #reboot. Chattr +i /etc/resolv.conf or chmod 444 /etc/resolv.conf as root fails. The VPN DNS servers #are only can originate from the vpn because they were not inserted anywhere else on the system.

SK (skiani) wrote :

I think this is related to my problem. vpnc worked fine in 8.04 and is now broken in 8.10. For me the resolv.conf the search entry is full of what looks like junk so I DNS calls to my connected domain don't work. If I manually edit after connecting to the domain I'm connecting to DNS resolves fine and I'm up and running again.

Florian Reinhard (freinhard) wrote :

got the same problem caused by a manual vpnc connection and Networkmanager on hardy(kubuntu). i wouldn't do that but knetworkmanager 0.7 seems to have lost a lot of functionality and usability since 0.2.2 (inlcuding vpnc connections). I found out that deleting /etc/resolvconf/run/interface/tun0, which contains all wrong entries messing up /etc/resolv.conf, fixed Gthe symptoms. So resolvconf doesn't seem to check whether the interface tun0 is up or not.

Try removing teh program resolvconf. This is NOT resolv.conf...after VPNing in to your network NetworkManager, not the program resolvconf, should be making the DNS changes to /etc/resolv.conf

code:
sudo apt-get remove resolvconf

Daniel J Simanek (tunads) wrote :

This issue also exists in Jaunty. The 'sudo apt-get remove resolvconf' work around is still applicable.

When I installed network-manager-vpnc, resolvconf came along as a dependency. Is that really necessary? Doesn't network-manager have all the same functionality built in anyway?

Alexander Sack (asac) wrote :

> When I installed network-manager-vpnc, resolvconf came along as a dependency. Is that really necessary? Doesn't
> network-manager have all the same functionality built in anyway?

my guess is that it gets pulled in by vpnc ... which is a vpnc packaging bug then.

Changed in vpnc (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Alexander Sack (asac) wrote :

... and yes, NM has all that is required to do VPNC without resolvconf. solution is probably to make resolvconf a suggest for vpnc ... or if vpnc doesant work at all factor the bits NM needs into a vpnc-core package or something that does not depend on resolvconf.

Changed in network-manager-vpnc (Ubuntu):
status: New → Invalid

I believe this is the same root problem as I'm seeing in Karmic. The vpnc generated nameservers get added to the *end* of the resolv.conf list, rather than the beginning. Thus, nameserver requests for hosts reachable over the VPN connection fail because the non-VPN nameservers respond first saying that the address does not exist.

A workaround is to reorder the entries in resolv.conf so that the vpnc generated nameserver is first. It is tedious to do this by hand every time one connects via VPN. This was not an issue in Jaunty (for me, at least). The real fix is to have resolvconf or whatever writes the resolv.conf file to put the vpnc generated nameserver first automatically. An even better fix would be to support split DNS for hostname resolution.

Daniel J Simanek (tunads) wrote :

>A workaround is to reorder the entries in resolv.conf so that the
>vpnc generated nameserver is first. It is tedious to do this by hand every time
>one connects via VPN.

Why not just do this?

>solution is probably to make resolvconf a suggest for vpnc

why go though all that work when you can just drop the dependency for a total unnecessary package?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers