resolv.conf overwritten using VPN/PPP etc...

This makes me a bit nervous, though, since it removes the possibility of updating name servers in non-VPN scenarios. At this point in the release cycle I'm too unconfortable with making such a change. I'll apply it early in Feisty+1.

Thank you for the workaround - now I can use VPN without DNS problems!

So, another thought for a solution would be to check if the original nameservers are still listed in resolv.conf. If they are, then only replace them.

Martin, let me know if this is appropriate and I'll throw up an appropriate patch.

Scott, can you please elaborate what you mean with 'the original nameservers are still listed in resolv.conf'? And yes, patches are always appreciated. :-)

actually i get the opposite -- my local nameservers are overwritten in /etc/resolv.conf during a VPN connection and they never go back to my original settings (nameserver 10.10.10.120) and if I manually change them after my vpn disconnect, somehow the unused VPN (or related programs) is/are changing the resolv.conf file BACK to the unwanted foreign nameservers :(

Ubuntu 7.04

I'm suffering from the same effect as lefty.crupps mentions (https://bugs.launchpad.net/ubuntu/+source/dhcp3/+bug/90681/comments/5)

Using NetworkManager to open PPTP tunnel from home my local DNS entries disappear.

Here how it looks like:
1. Connected to local (WiFi) network
"""
cat /etc/resolv.conf
# generated by NetworkManager, do not edit!
search lan
nameserver 192.168.1.1
"""

2. Connect to remote site PPTP using NetworkManager
"""
cat /etc/resolv.conf
# generated by NetworkManager, do not edit!
"""

3. Disconnect from remote site PPTP, local resolve.conf restored.

The optimal solution would be NM "merging" both configurations, making the "nameserver" records came from the remote site as additional (lower priority) query options. The same for "search" domain names (if at all multi selection is possible). Upon disconnection the same action in reverse order should occur.

I can confirm that I'm seeing the same bug with 32bit Feisty. The problem I am seeing is exactly the same as what has been described above - if the underlying interface has short DHCP lease, and it is renewed whilst the PPTP tunnel is enabled, then traffic will not be interrupted continue, but resolv.conf will be overwritten by dhclient.
I have applied the workaround (not updating resolv.conf when renewing leases) - though I can agree that is far from optimal. I was thinking of hacking the script so that it searches for a "ppp" interface in ifconfig to verify that a PPTP (or any VPN?) tunnel is up - and therefore do not force a update.
However, the more elegant solution would be if NM can detect and handle a DHCP renew (which isn't possible, as NM is simply a wrapper for dhclient and other underlying processes?) - and merge the new nameservers (in the case that they have changed since last lease? Unlikely, but possible?) with the existing VPN ones. This is elegant in that it will respect the USEPEERDNS option of the tunnel.
And in response to hq4ever - I believe you are experiencing another bug - one where NM does not respect the USEPEERDNS option - in a nutshell: if it is selected, then it works - if it's not, then NM replaces the existing resolv.conf with an empty one - which is not expected behaviour. See: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/37239 ?

I've seeing the same thing but with a command line openvpn connection. However the patch to the script didn't seem to work. In my case the initial connection is being handled by wpa_supplicant and uses dhclient not dhclient3

I confirm I have this bug too

In Gutsy I now have a similar problem:

- Network Manager writes the VPN's DNS to resolv.conf
- For some reason Firefox/Evolution/any network program don't use it.

In Feisty VPN and its DNS worked fine for the network-manager OpenVPN plugin, in Gutsy no more.

Any ideas/input would be much appreciated. Thanks!

Same bug in Gutsy.

Open WIFI, get DNS from my local router.
Open VPN Connection, lost DNS information
Close VPN
Return to default DNS from my local router.

I am getting this in gutsy with network manager with the PPTP plugin.

when i connect to a windows vpn server it overwrites my local resolv.conf with a blank one. I can then edit details back in.
when disconnecting the vpn it puts the original resolv.conf back and overwrites any changes.

Is there anyway of telling network manager what to put in resolv.conf that i have missed?

Thanks for the good hints. I only use cisco vpn client (vpnc) for networkmanger. vpnc creates a new interface tun0 when the vpn is open. So I enhanced the first mentioned patch by checking whether a tun interface exists. If there is tun interface up dhclient continues as usual otherwise it doesn't do anything to resolv.conf.
If other vpn solutions create other interfaces the awk line should be extended accordingly.

BTW the patch is for ubuntu 7.10, package dhcp3-client version 3.0.5-3ubuntu4

Well, I don't understand much this bug but find it funny that bug #37239 is almost the reverse:
(VPN connection should alter /etc/resolv.conf)
Don't really know if this is related to this bug.

The behaviour varies because the resolver configuration file gets overwritten each time the lease is renewed. There are two contending parties: the local provider and the remote provider; which party wins depends on which lease expires earlier (more often). I agree it is unmanageable; indeed, the resolver configuration should be a union of information provided by all sources, not just one of them taken on last-wins basis, and there must be an option to deny all influence on the resolver configuration from remote connections, or preferably connection-wise (it slows down the resolver a lot if it goes through the tunnel for all queries).
It would be much more pernicious if the default gateway were replaced in the same way; fortunately it is not the case.

My problem is related: I want to *add* an extra domain to my "search" list, so I modify /etc/resolv.conf and my changes to it are lost shortly afterwards (on reboot, or on DNS renew).

If there was another config file where I could place additional 'search' domains or DNS servers, or DNS servers themselves, then it could be added to resolv.conf when it gets overwritten, and that would solve my problem.

okay, so this is my understanding of how things should work:

1. on a local network without DHCP, resolv.conf is configured manually by the user
2. on a local network with DHCP, resolv.conf is set once at connection time, but then may be updated each time the DHCP lease is renewed
3. on a remote network (via PPP or VPN), resolv.conf contains the merge of local and remote settings, and is set once at connection time, but then may be upated each time either of the leases are renewed -- both local and remote
-- 3b. if the remote network does not provide DNS information then resolv.conf should be left unchanged
4. when the remote network connection is brought down, resolv.conf must be restored to either its state before the conntection was established, or -- if the local lease was renewed during this period -- to its latest lease value

one way for this to happen would be for NM to take a copy of resolv.conf at the point it establishes the connection, and then have it listen to resolv.conf for update notifications. if resolv.conf is changed by some other party (e.g. dhcpclient or dhcpd) then it can update the copy of the file that it will use to restore when the connection ends, and can also recompute the local/remote merge.

@alan ezust: perhaps other people can tell you how it is done for the time-being, but I happen to know that what you want is coming in a nice gui form in the yet to be released, NetworkManager 0.7.

here is a script for if you don't want to apply this patch yourself, or you don't like the idea of losing dynamic DNS updates. it must be run as root (sudo), and started up as soon as you have connected to your VPN:

#!/bin/bash
if [ "$1" = "restore" ]; then
 if [ `grep -c "# forcibly restored" /etc/resolv.conf` = "0" ]; then
  cat resolv.conf.orig > /etc/resolv.conf
 fi
else
 # uncomment this line to set the default domain on the remote network
 #echo "domain acme.com" >> /etc/resolv.conf

 echo "# forcibly restored" >> /etc/resolv.conf
 cp /etc/resolv.conf resolv.conf.orig
 dnotify -M /etc -e `pwd`/$0 restore
fi

The "merge" behavior is unacceptable in some setups, where the same name resolves to different IPs depending on whether you're inside or outside of the firewall. There should be a config option to have the VPN DNS completely override the local DNS when the VPN is active.

In that case, maybe the VPN DNS can be inserted *above* the existing DNS servers?

just a thought:

I use VPN extensively and to multiple endpoints. Before I was using MS VPN client, which had the convenient "use default gateway on remote network" option. This option is absent from network-manager GUI, a similar functionality can be achieved with "only use VPN connection for this addresses" field on routing tab.
That being said, the DNS records in /etc/resolv.conf should be a merge of multiple scenarios - manually entered DNS records (from network-manager manual config), automatic DNS hosts from DHCP, and when connected, DNS hosts from VPN connections. This should be inserted before all other if the connection uses the default gateway, and after all other if it uses only the target LAN IP range.
The mysterious "use peer dns" and "peer dns through tunnel" options seem to be broken as well (Bug #37239), so complete solution is somewhat broken... I would opt for a simpler config interface, maybe with "advanced" tab for all the strange configs geeks use and a set of simple straightforward options for the rest of us ;)

 I am on Gutsy. When i connect to the office vpn my local dns and local search entries which are set by my local DHCP Server disappear, the remote nameservers have entries, but none of the remote search domains i want are present unless i add them. (After disconnecting the original settings are back.)

I agree with the comments that the /etc/resolv.conf file should contain (or the option to have it contain) a merge of local and remote. I would also like to see the option in the vpn setup to add search domains - my office uses several because of acquisitions, and production network separation projects.

I thing all the configuration that you want to do can be done in /etc/dhclient.conf or similar.

you can lookup information from the command line in man pages:
man dhclient.conf

Hope this helps.

David

David,
in a way you are right. I can either redefine the client script and put
my own or I can take care that the ip is never renewed. I think it would
be better to a have a default configuration in ubuntu that leaves
resolv.conf alone when a vpn has been opened.
Rgds
 Markus

David schrieb:
> I thing all the configuration that you want to do can be done in
> /etc/dhclient.conf or similar.
>
> you can lookup information from the command line in man pages:
> man dhclient.conf
>
> Hope this helps.
>
> David
>
>

I took a stab at writing a script to be put into
/etc/dhcp3/dhclient-enter-hooks.d to try and fix this problem. It is
quite simplistic, and simply unset's new_domain_name_server if the value
is the same as old_domain_name_server and reason is RENEW.

The logic is, if it's a RENEW and the name server hasn't changed, then
resolv.conf is either still up-to-date from when we BOUND the lease or
it has been updated by some other program. In either case, we can leave
resolv.conf along and assume it's contents are good.

Really though, this logic should be in dhclient-script itself. After
all, dhclient-script checks other important data to see if it's actually changed
rather than just blindly updating it. There is no reason why the
nameserver should be different. I can't think of any case where 1) it's
a RENEW and 2) the nameserver hasn't changed, where updating resolv.conf
is safer/better than leaving it alone.

Try installing resolvconf (apt-get install resolvconf)

BeBoxer: Thanks for that little script - works like a charm.

Installing resolv.conf had been the solution for me, though it ain't no longer a solution.

Some of the recent updates in the run-up to (still beta-buggy) 8.04 something installed that neuters the soultion via resolv.conf. In NetworkManager - Manual Configuration I have saved several configurations with different DNS servers. Before connecting to the VPN, I load one of them manually. Super-weirdly, the system needs a minute or two to get used to the alternate settings. Or you restart networking.

Anyway, it ain't what it should be, and a permanent fix to this would be highly desirable, to make Ubuntu fit for a production environment. At this time, it is not fit for that.

Still applies with 8.04 release.

Using 7.04. Latest updates applied. This is still...still...still a problem.

For now I just have a copy of the correct resolve.conf that I copy over the old one when I connect to my vpn. I have my vpn connection set to not use any of the dns stuff from the vpn server and have network-manager set only to use the vpn for a particular ip range. So when I connect to the vpn my resolve.conf just gets blanked out. I even manually set DNS info for my wirless setting in nm and that just gets dropped as soon as I vpn.

I'll try some of the work arounds later, but this really should be resolved.

I hit this too; my company uses Juniper's NetworkConnect and it adds its own DNS servers as the first ones to search to /etc/resolv.conf. I disabled the download of the DNS server info altogether which is obviously not optimal, but works OK for me because I've installed a Linux image on my Linksys router and enabled dnsmasq, so my local LAN DNS server is always my router, which never changes, not my upstream ISP. But, when I configured a laptop for a friend they have this problem in spades.

To me, anything that watches for changes to /etc/resolv.conf and tries to change things back again is just not reliable enough. Ditto for having scripts depending on seeing a tun0 or ppp0 or whatever interface.

I think the right answer HAS to be a smarter dhclient script. It's the only one that seems reliable and robust. An easy answer that will help most of the time was already suggested: if the hostname to be added to resolv.conf already exists, then don't change resolv.conf. This seems like something that is obviously correct and won't cause any problems.

This works for me because my VPN solution leaves the original nameserver entry in /etc/resolv.conf, it's just put at the bottom. I suppose some people might have problems if their VPN solution completely replaces /etc/resolv.conf. That might require a more sophisticated solution.

"I suppose some people might have problems if their VPN solution completely replaces /etc/resolv.conf. That might require a more sophisticated solution"

This is the case for me. My resolv.conf gets replaced whenever I connect to my vpn. This is to avoid doing dns resolution on an untrusted network (e.g., free wifi at coffee shop). Also in cases where the network I'm on is sandboxed, such as the wireless segment of my lan, there is limited DNS resolution available. In this case, full dns resolution must be done at the trusted end of the tunnel.

When the dhcp renewal blows away my "trusted" resolv.conf, then the result is either that DNS resolution moves to the untrusted network, or DNS resolution breaks because resolv.conf now points to the sandbox DNS address.

I've updated Markus K's patch to also check for Cisco's proprietary VPN client (interface name cipsec0). This happens to work for me because my VPN only uses DNS over the VPN so no matter what happens locally resolv.conf shouldn't change.

Thanks, Philip! Two questions:

 - It looks like this patch would stop renewing leases for *all* interfaces if *any* interface is using a VPN.

 - This looks very complicated to me:

       [ -n "( ifconfig -s | awk ' ( $1 ~ /^(tun|cipsec)/ ) {print $1}' )"]

   I'm no awk guru, but isn't that the same as

       ifconfig -s | egrep -q '^(tun|cipsec'
   ?

Hi,

I think I get the same problem here on my 8.10. I connect to different wireless LANs with my notebook. I also use openvpn and vpnc. My problem ist, that dhcpcd somehow REMEMBERS its resolv.conf configurations and still applies settings from different WLANs or VPNs when I connect to new WLANs.

I have to edit my resolv.conf every time manually.

Michael.

Hi,

When I started my notebook looking at the log entries I saw something like:
resolvconf: unable to remove (...)/eth1/resolv.conf. File system read only.

This entry does not appear in dmesg and syslog. But the behaviour is reproducable evey system start. Perhaps this helps fixing this annoying bug.

Thanks.

Michael.

Any updates? Is there a patch in the works for this?

I installed jaunty and some of this is fixed - new NetworkManager is much more straight-forward as far as routing settings are concerned, and resolv.conf gets updated (with target DNS appearing before others in the file). I am still missing a connection-specific search domains, though...

I have Jaunty (Netbook Remix) here with the same problem.

I use blueman instead of bluez to establish PAN networking.

I tried blueman in both of its modes
- blueman handles the interfaces
- let the network manager handle the interfaces

In both cases i experience the resolv.conf being overwritten regularly.

I also want to have my - maybe connection specific - search order present there.
(Its a lot of hassle to write FQDNs with the saaaame.looong.tld :)

Tamas Herman wrote:
> I have Jaunty (Netbook Remix) here with the same problem.
>
> I use blueman instead of bluez to establish PAN networking.
>
> I tried blueman in both of its modes
> - blueman handles the interfaces
> - let the network manager handle the interfaces
>
> In both cases i experience the resolv.conf being overwritten regularly.
>
> I also want to have my - maybe connection specific - search order present there.
> (Its a lot of hassle to write FQDNs with the saaaame.looong.tld :)

Here is the ugly workaround I use that has the advantage of working all
the time (I'm on a network where the DHCP lease time is around 10
minutes as part of the authentication system).

You'll of course want to replace the name (office.fsf.org) and and
address (192.168.0.25) of my private-network name servers with yours ,
and change the .in-addr.arpa lines to be your private network ranges.

=== Try at fixing PITA DHCP Lease Renewal breaks DNS problem ===
See also the Ubuntu bug
[https://bugs.launchpad.net/ubuntu/+source/dhcp3/+bug/90681/ resolv.conf
overwritten using VPN/PPP etc..]

* replace network-manager with [http://wicd.sourceforge.net/download.php
wicd]
* aptitude install dnsmasq
* remove the lines beginning with "script-security", "up", and "down"
from /etc/openvpn/client.conf
* Set /etc/resolv.conf to always point to the dnsmasq name server:
  rm /etc/resolv.conf
  echo nameserver 127.0.0.1 > /etc/resolv.conf
  chmod 444 /etc/resolv.conf
  chattr +i /etc/resolv.conf

* Make one of these your /etc/dnsmasq.conf file:

<pre>
#
# /etc/dnsmasq.conf minimal version
#

resolv-file=/etc/resolv.conf.dhclient-new
server=/0.168.192.in-addr.arpa/192.168.0.25
server=/0.16.172.in-addr.arpa/192.168.0.25
server=/office.fsf.org/192.168.0.25
</pre>

--
Daniel JB Clark | Sys Admin, Free Software Foundation
pobox.com/~dclark | http://www.fsf.org/about/staff#danny

Hello

I've been having similar problems and looking for a long time for a solution. Finally seems to have solved my problem.
I do not understand how different installed packages decide to modify /etc/resolv.conf and sometimes without consideration to each other. In my case, I use NetworkManager to manage my connections.

Simply put, the solution was to remove the package "resolvconf" and use "networkmanager" for wired, wireless and vpn.

If you are using vpn connections, configure it through network manager (nm) and not through some other utility. There's a vpn for networkManager you need to install first.
If you don't use the nm-vpn like I was, for a few minutes you have /etc/resolv.conf set up properly with the vpn dns , search and domain settings but sooner or later nm will overwrite your files and your vpn will be broken.
So, using vpnc from the command line or other vpn tools won't do.

I hope this helps others.

As a suggestion for Ubuntu packagers, when installing networkManager, resolvconf should be one of those conflicting packages. Of course, there's probably a better solution.

Cheers

Chahé

Is anyone ever going to do anything about this? I know it's not an easy problem but there are solutions here which will help at least some of the people and which are not harmful (for example, not updating /etc/resolv.conf on RENEW if the old nameserver is still present).

If we could do at least that, then we'd solve this problem for a lot of people with little effort and no deleterious effects.

Please??

Adding domain info to "/etc/dhcp3/dhclient.conf" should fix this issue. This file will add domain info to "/etc/resolv.conf" (and will work with or without VPN). Use the following steps:

1.) At the terminal enter "sudo gedit /etc/hdcp3/dhclient.conf" (without quotes)
2.) find the line "#supersede domain-name "fugue.com home.vix.com";"
3.) remove the "#" sign at the front of the line to uncomment it.
4.) add your domain names to the line, i.e: "supersede domain-name "mydomain.com workdomain.com";"
5.) reboot

I'm not sure why you think retrieving domain info from the DHCP server will do anything to help the problem, which is that the Ubuntu DHCP client is overwriting the resolv.conf file and replacing nameservers that were added due to VPN connections.

How to update nameserver in Network Manager and stop it from changing the /etc/resolv.conf after rebooting in Ubuntu 9.04 to 10.10

1. Open Terminal and type sudo su then press enter.

2. Type in gedit /etc/resolv.conf then press enter, you will then see your Network Managers nameserver usually 198.168.0.100, write down whatever the ip is then close terminal.

3. Right click Network Manager and select Edit Connections, left click Wired or Wireless, then left click Auto eth0 or eth1 or Auto whatever the name is for the wireless connection, left click Edit, then left click IPv4 Settings, tick box connect automatically, look at the Method box if it says Automatic (DHCP) left click the box and select Automatic (DHCP) addresses only, look at DNS servers and write in the box ***.***.***.***, ***.***.***.***, 192.168.0.100 or the ip you wrote down if it is diferent ( DO NOT TYPE THE *** TYPE IN THE IP NUMBERS OF THE NAMESERVERS YOU WANT TO USE), the commas are important as they are used to seperate the namservers addresses in the /etc/resolv.conf. Tick box Available to all users then left click apply and then type in your computer password when prompted and press apply. The first 2 nameservers are the nameservers you want to use and the 3rd is your DNS nameserver. Reboot and perform step 1 an 2 you will find the nameservers you typed in the Network Manager have not been changed.

I've been duct-taping my way around this issue (and other similar issues) for years. It's terribly kludgy, but it's simple and effective and doesn't break on each upgrade:

  /etc/init.d/openvpn start
  while true ; do cp /etc/resolv.conf.good /etc/resolv.conf ; sleep 15 ; done

Or something like that, anyway. I actually run 'vpn up' and 'vpn down', but the above is how it deals with having too many cooks in the DNS kitchen.

This is still an issue in 16.10 and 16.04