n-m-openvpn: resolv.conf is erased if endpoint does not push DNS servers

[Robin Sheat]

Binary package hint: network-manager-openvpn

I connect to a VPN, and I tried to use network-manager-openvpn to do it. This network doesn't have it's own DNS server, and so doesn't push that information through. However, n-m-o erases the existing contents of /etc/resolv.conf anyway, removing the original entries in there. The VPN is only used for certain hosts, it's not one that I route my whole connection through, and so this ends up breaking things. If I use nm-applet to disconnect the VPN then the resolve.conf entries for the LAN are re-written as per normal.

It probably should detect either if no DNS details were sent from the server, or if the "Only use VPN connection for these addresses" box is ticked, and leave resolv.conf as it is if this is the case.

This is on the Feisty beta.

[Thomas Black (tsblack)]

I can confirm this bug. I also use it for specific nets and I need to manually add the nameserver each time.

[Michael Trunner (trunneml)]

Same problem here, so I can confirm, too. If this is fixed, a have a solution for bug #88069.

[magic- (olaf-ippisch)]

I can confirm this also on the Feisty final version. Our university net uses openvpn for the whole transmission, but as the dns information is already set by the
wlan connection it doesn't seem to retransmit them. In any case finally the resolv.conf is overwritten with an empty file.

[Alessandro Gervaso (gervystar)]

I can also confirm this: I use openvpn to connect to my workplace's network and now I'm using the command-line because of this bug. This is a blocker for my less expert colleagues.

[Michael Trunner (trunneml)]

Hi all,

I have writen a fix for this bug.
I think the problem isn't in the openvpn plugin, because it only told networkmanger that there is no nameserver. I think the problem is that networkmanger write a resolv.conf with no nameserver when activating a device.
So that's the reason why my patch is for network-manager package and not for the openvpn plugin.
Please can anyone test if it works for him, too.

[TomasHnyk (sup)]

Hi, it work for me (I followed the steps to build the package you posted elsewhere:
1. $ sudo apt-get build-dep network-manager
2. $ apt-get source network-manager
3. place the patch file in debian/patches
4. $ sudo debuild -us -uc # if this does not work you need devscritps package).

That I still cannot use my connection witn network manager is a wholly different issue:-(.

[Michael Trunner (trunneml)]

Hi TomasHnyk,

look at bug #88069. After fixing both I can use networkmanger-openvpn without a problem. Hope this helps you.

Tschö

Michael

[Martijn Evers (mevers)]

Same problem here,

Tried the patch but it won't work. nm is still overwriting /etc/resolv.conf.

local eth0 dhcp client (good):
> # generated by NetworkManager, do not edit!
>
> search RtS
>
>
> nameserver x.x.x.x
> nameserver x.x.x.x

nm - openvpn plugin connecting... no dns information found so /etc/resolv.conf is empty:
> # generated by NetworkManager, do not edit!
>
>
>
>

In the openvpn plugin i can choose to set the option 'Only use VPN connection for these addresses'. Which i use because
i only need openvpn to connect to two remote hosts. Like Eythian said, it must not modify /etc/resolv.conf when this option is enabled.

[Ross Williams (ross-ross-williams)]

Word to the wise:

I think this bug is connected to an underlying lack of control of DNS settings by network-manager. It seems like the daemons NM invokes (openvpn, dhcp3, etc.) modify resolv.conf on their own accord in a way that's not controlled by or compatible with NM. For example, see <https://bugs.launchpad.net/ubuntu/+source/dhcp3/+bug/90681>.

[Robin Sheat (eythian)]

If you invoke openvpn manually, it doesn't modify resolv.conf, so I'm somewhat sceptical this is what is occurring in this case.

[Ross Williams (ross-ross-williams)]

You are correct. I made a quick assumption. What is happening is that network-manager-openvpn (nm-openvpn-service.c) is putting a message onto DBUS of type NM_DBUS_VPN_SIGNAL_IP4_CONFIG. That causes nm-vpn-service.c to call nm_ip4_config_add_nameserver(). Seems like all is as it should be in network-manager-openvpn. I propose that this is an upstream bug in network-manager, specifically in nm-vpn-service.c.

[Soren Hansen (soren)]

IIRC the bug is that the openvpn plugin sends an empty list of name
servers and network-manager accepts that and deletes the current list.
What needs to be done (I think) is to change network-manager to not do
anything if it receives an empty list of name servers.

--
Soren Hansen
Ubuntu Server Team
http://www.ubuntu.com/

[Michael Trunner (trunneml)]

My patch above do that. When the nameserver list is empty it will not update the resolve.conf

[Tobias McNulty (tmcnulty1982)]

I can confirm this bug. I tried the patch and it fixes the problem. It's easy to build but if you don't want to bother, I've posted a binary:

http://www.ppckernel.org/~tobias/ubuntu/feisty/

Just download it and run <code>sudo dpkg -i network-manager_0.6.4-6ubuntu7_i386.deb</code>

Thanks for the fix.

[Philipp Kern (pkern)]

This bug breaks sensible VPN access.

[Philipp Kern (pkern)]

Hi network-manager bug wranglers,

this bug report has a patch which lets named-manager refuse to update resolv.conf if the update will result in no nameservers being written to `/etc/resolv.conf' (which could happen with openvpn if no DNS server is pushed by the remote endpoint). Does it look sane to you, and if so could you please apply it?

[Philipp Kern (pkern)]

Lowering the importance for network-manager-openvpn as a workaround (let the remote endpoint push DNS settings) exists.

[TomasHnyk (sup)]

Philipp:
Are you refering to the patch by Michael Trunner? Would testing the package by Tobias McNulty suffice you? I almost broke my system the last time I tried to apply a patch to network-manager.

[Michael Trunner (trunneml)]

I'm using my patched packages the hole time on the university network, without problems. The DNS still exists and the routs are configured.

@Philipp Kern:

Sorry your workaround isn't working for me and many others. Because I can't go to the administrator of the university network and say: "Please change your configuration ...". The answer is a big "NO".

I think when an vpn connection is established and a dns server is pushed, then the the new dns should be used. And if no dns server is pushed, there should be nothing changed in the resolve.conf.

What do you mean?

[Philipp Kern (pkern)]

You can ask the administrator of the university network at least. If you get full routing pushed by the endpoint, then you don't want to use your local DNS servers and even if you don't you probably get access to some intranet which probably requires other DNS settings, too.

I assigned this bug to n-m, because the patch needs to be applied there, not in the openvpn plugin and because n-m is a core package. There's nothing I could do except for waiting for input from the n-m maintainers.

[Michael Trunner (trunneml)]

I was by the administrator and he said no. Because of i had written this patch/workaround.
The n-m Team told me that the new version has fixed this problem.

[Philipp Kern (pkern)]

network-manager guys, could you please look at the patch attached to this bug report and if it would be ok to apply that to n-m proper?

[Alexander Sack (asac)]

I already asked about that on IRC, but didn't get a proper answer:

which use-case would be fixed by just keeping the old/outdated resolv.conf?

[Robin Sheat (eythian)]

The use-case of 'able to use the internet' :) It's not always the case that the whole connection is pushed through the VPN. In my case, I have a few hosts (internal work servers) that are defined by /etc/hosts entries that I use the VPN for, and all other traffic goes over the regular internet. If /etc/resolv.conf gets wiped, then the latter part stops working. If it remains, then you get to keep the nameservers that your regular DHCP setup gave you.

[VDR (vdr)]

Some examples:

1) We have internet via VPN server -- vpn server push DNS settings, IP etc.
Connections via ie. ethernet is only for connect to openvpn server.
Default route via VPN tunnel.

2) We have internet via ethernet cards -- we use vpn only to connect to specific hosts.
We connect to VPN hosts and use only point to point connections. VPN server *DON`T PUSH* DNS settings.
resolv.conf is wiped. We have connection to specific host via VPN (route is in table for this
subnet) but default route is set by ethernet cards. We have connection to Internet via ethernet cards but we don`t have
DNS in resolv.conf so Internet doesn`t work.

3) We have internet via ethernet cards -- we use vpn only to connect to specific hosts.
We connect to VPN and make point to point only connections. VPN server *PUSH* DNS settings.
We connect via VPN, and in resolv.conf we have DNS settings from VPN server . We have connection to specific host via VPN (route is in table for this
subnet) but default route is set by ethernet cards. We have connection to Internet via ethernet cards but Internet doesn`t work, because DNS server is in another subnet than vpn connection, and VPN server don`t push route to this subnet. We connect to this DNS by default route via ethernet cards and we have problem because DNS allowed recursion only for local subnet.

Sorry for my English, but I think that this examples is helpfull ?
I think that one small options in Options Tab: "pull DNS settings from VPN servers" in network-manager-openvpn will be helpfull ;) When we have choice, we can manually set what we want and have more combination.

[Alexander Sack (asac)]

the problem i see is that this fix would just fix _some_ symptoms, while others are still unclear or even worse get more confusing. Imagine you have three networks, first you connect to network A, then you switch to VPN (without DNS push) ... now you end up using the resolv.conf of Network A. second you connect to network B, and you switch to VPN (without DNS push) ... then you will end up using the resolv.conf of network B. For the user this is all opaque and is probably more confusing than just recognizing that the VPN isn't setup properly (e.g. no nameservers are pushed).

[Philipp Kern (pkern)]

You cannot connect to a VPN if you are already connected to a VPN.

[VDR (vdr)]

one more example:

I have bind/powerdns etc. on my local machine ;) I never need use another DNS because have own.
So I don`t need a pull dns settings from openvpn server even openvpn push this settings properly ;)
Actually it`s irritated because when I use openvpn connections I must manualy write nameserver options to /etc/resolv.conf

[Alexander Sack (asac)]

Can you please attach /var/log/syslog where you connected to a vpn _without_ DNS push? If possible attach another log that connected to a VPN _with_ DNS push.

Thanks,
 - Alexander

[VDR (vdr)]

1) vpn-without-dns-push.txt -- I connect and disconnect to vpn server without push dns options
2) vpn-with-dns-push.txt - I set push dns options in openvpn config and connect and disconnect to vpn server

[MrYutz (gregbazar)]

This is a critical bug for our organization. Our VPN does not push DNS - so the user simply sees a broken network once they connect.

Our VPN is used for file and email access via the web, and the user can still be connected to the internet via their local network.

The patch fixes the problem - but makes it impossible to keep up to date with Ubuntu relases. I just installed Gusty and it has the same issue - and am re-compiling the patch to network manager 0.6.5

[Fabus (fabian-gebert-hh)]

I totally agree with you, that bug should be fixed. At least for me it was enough to just install the resolvconf package.

[Diginin (shawn-beasley)]

A quick and dirty work around is to sudo /sbin/dhclient right after the vpn is running. This will rewrite your resolv.conf with the current lan settings. After disconnecting n-m just does its thing again and writes the resolv.conf correctly. It is not sophisticated but it works.

[Petr Menšík (pihhan)]

Please tell me if this problem is considered buggy or not. From my point of view it is clearly bug. I have access to two VPNs. One PPTP to my school, where it does not supply DNS as it is not needed anyway. I have router all network there via vpn and DNS is not on LAN subnet, so it is securely routed via VPN too. Oh it should, because right after connecting to VPN, it clears my DNS and i have nothing. So i have secure ping to ip addresses, or working general internet connection. I am not administrator, i am not able to change its behaviour. I can change only my laptop.

I have also my own openvpn VPN. It has password authentication and it works quite well. But of course, DNS does not work neither. I wanted to push only some routes, and this does not work. Well, it is simplified by GUI, i accept that. Instead of centrally managable routes i have to set them in every client. But Why some things does not work, when i HAVE to push DNS settings to keep it working?

I have gutsy installed and feisty users reported already. So problem is not new, still no official fix is available. I think all that is about if dns_empty dont change /etc/resolf.conf. Will it be fixed at least in Hardy?

[Mark A. Hershberger (hexmode)]

I am having this problem with a VPN that I set up.

This is a VPN for the express purpose of connecting to a single host in a remote country behind a firewall. Since this is essentially a management VPN for one (more later?) machine, I absolutely do not want to set up a nameserver. I would prefer to use a local nameserver.

Another use case: A co-worker and former Yahoo! employee told me that Y! put all their private names on their public DNS. So a Y! VPN user could continue using the local DNS server even after they connected to the VPN. I've no idea if Yahoo! still does this, but that would certainly be another use case for fixing this bug.

As it is it doesn't look like Hardy has the fix (http://packages.ubuntu.com/network-manager-openvpn) since the version in Hardy is the same as in Gutsy. I'll look around for a PPA with a fixed package and if one doesn't exist I'll publish a fixed package in my PPA.

[Mark A. Hershberger (hexmode)]

First, of course I was wrong, Hardy has a different version of NM, I pointed to the openvpn component. http://packages.ubuntu.com/network-manager

Looks like NM has this fix upstream (http://svn.gnome.org/viewvc/NetworkManager/trunk/src/named-manager/nm-named-manager.c?r1=3154&r2=3212&view=patch) to fix the upstream bug: http://bugzilla.gnome.org/show_bug.cgi?id=346833

Doesn't look like Hardy has the fix :(

asac's PPA does, though:
https://launchpad.net/~asac/+archive

[Christian Paratschek (christian-paratschek)]

I can confirm comment 32 by Fabus. Installing the package "resolvconf" fixes this problem - or at least its symptoms :-)

[Indiver (indiver)]

I can confirm this bug. I tried installing package resolvconf as Fabus told and it fixed the issue.

[Alexander Sack (asac)]

bug 256480 takes care that resolvconf works. this on top of the general improved capability of NM 0.7 should fix this. Marking this bug as fixed for next upload.