Bug 244274 - NetworkManager creates empty resolv.conf with networkmanager-openvpn
NetworkManager creates empty resolv.conf with networkmanager-openvpn
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: NetworkManager-openvpn (Show other bugs)
7
All Linux
low Severity low
: ---
: ---
Assigned To: Tim Niemueller
Fedora Extras Quality Assurance
:
: 253438 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-14 15:40 EDT by Pedro Fernandes Macedo
Modified: 2008-05-05 17:10 EDT (History)
3 users (show)

See Also:
Fixed In Version: 0.6.6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-05 17:10:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch for nm-openvpn (25.19 KB, patch)
2007-09-18 08:52 EDT, Christoph Höger
no flags Details | Diff
Custom DNS Patch (40.24 KB, patch)
2007-09-20 12:56 EDT, Tim Niemueller
no flags Details | Diff
glade file for properties page (103.88 KB, application/x-glade)
2007-09-21 08:17 EDT, Christoph Höger
no flags Details

  None (edit)
Description Pedro Fernandes Macedo 2007-06-14 15:40:41 EDT
I've filled the bug under NM since the bug report on 
https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/96260
seems to indicate that the issue is with NM (specially the patch  
http://launchpadlibrarian.net/7496007/23_openvpn_workaround.diff works around
this problem directly in NM instead of NM-openvpn).

Scenario: vpn only for a few subnets, default gateway is the same as before
starting vpn. The remote openvpn server doesnt push any DNS servers, just
routing information.  When the vpn is enabled through NM, it results in a blank
resolv.conf, only containing the comment saying it was generated by NM. 

Version-Release number of selected component (if applicable):
NetworkManager-0.6.5-3.fc7
NetworkManager-glib-0.6.5-3.fc7
NetworkManager-gnome-0.6.5-3.fc7
NetworkManager-openvpn-0.3.2-7.fc6

How reproducible:
100% reproducible on an openvpn vpn where the server doesnt push DNS servers to
its clients.

Steps to Reproduce:
1. configure a vpn with openvpn where the remote server doesnt push any DNS
information at all and also where there's no "redirect gateway" option enabled.
2. start vpn
  
Actual results:
resolv.conf containing no DNS servers

Expected results:
resolv.conf should retain the DNS servers, since we're not redirecting the gateway.
Comment 1 Christoph Höger 2007-09-04 17:58:59 EDT
I can absolutely reproduce this bug. 
Can someone provide a testpackage with the patch?

regards

christoph
Comment 2 Alexey Kuznetsov 2007-09-16 10:04:13 EDT
*** Bug 253438 has been marked as a duplicate of this bug. ***
Comment 3 Christoph Höger 2007-09-18 08:52:59 EDT
Created attachment 198331 [details]
patch for nm-openvpn

This patch adds the option to select a distinct dns for each openvpn connection
or to use the pushed dns information or both.
Comment 4 Christoph Höger 2007-09-18 08:55:22 EDT
The patch above needs NM to be patched with
http://launchpadlibrarian.net/7496007/23_openvpn_workaround.diff
to work properly. 

So if this is not already in upstream I would suggest to add it ASAP.
Comment 5 Tim Niemueller 2007-09-18 09:15:35 EDT
I'm going to give it a try tonight.
Comment 6 Tim Niemueller 2007-09-18 17:07:20 EDT
Do you want to use 23_openvpn_workaround.patch such that the resolv.conf content
is not overwritten if no name server has been supplied by the VPN connection?

I think in that case this can cause problems. In general I'd assume that the DNS
server currently used is "close" in network terms, for example being in the same
wifi hotspot or so, while the VPN server which is going to be the default
gateway is "far" away, in the company or university network. In many cases the
close DNS will even be on a private IP address, such that accessing the DNS
server over the VPN will not work and there are now local routes for the DNS. On
the other hand is doesn't hurt. The worst thing that can happen is that no DNS
is reachable (but this seems likely).

I also think that we can slim down the patch. We only need one field saying "Use
custom DNS". If that is not selected we just use the DNS supplied from the
OpenVPN server as this is the expected behavior in the first place.

I'm going to reassign to NetworkManager-openvpn component as it is really a
problem there, not in NetworkManager in general.
Comment 7 Christoph Höger 2007-09-18 17:32:43 EDT
Yes I think that the 23_openvpn_workaround.patch is generally neccessary as NM
should not write an empty file. I think we could see this as fallback behavior.

This can IMO not cause more problems than we have already now but helps out in
cases when the openvpn server does not push any dns infos but the client uses
special routes (in my personal case I want only to reach the servers at work,
not route my private traffic over the vpn).
We could solve the problem you mentioned perfectly by adding the custom dns
field (it should be even possible to check if one of the last dns servers will
still be reachable with the new routing and post a warning if not, but that
would require a lot more work ;) ).
 
But in case of domains in /etc/resolv.conf they will be lost and the user still
has no choice at all to keep his local settings as they are (which was my
original motivation). 

So we need the opportunity of keeping local settings as they are, or support a
full featured /etc/resolv.conf file for each connection.
Just to keep the patch simple I preferred the first option, which of course
could be handled by checking for an empty dns entry instead of using an own
checkbox.

Do you need any more input (modified patch or something)?
Comment 8 Tim Niemueller 2007-09-20 12:56:23 EDT
Created attachment 200951 [details]
Custom DNS Patch

Find a modified patch attached. This patch eliminates the "pushed-dns" setting
thus just allowing to override the DNS with a custom DNS or using the old
behavior. I did also several changes to the GUI, and not only to the custom DNS
stuff but that's what I had lying around anyway.

I can't test it here at the moment so please give it a try.

The patch is against the 0_6_0_RELEASE branch (see
http://svn.gnome.org/viewcvs/NetworkManager/branches/NETWORKMANAGER_0_6_0_RELEASE/).
Please use this one when you try.
Comment 9 Christoph Höger 2007-09-20 16:21:37 EDT
looks perfect. Thank you.

btw: you _could_ slim down the buttons in the TLS-Auth section a little bit ;) 
Comment 10 Tim Niemueller 2007-09-20 18:43:18 EDT
Ok, if that works I'll commit.

If someone tells me how to trick the VBox to not use the full space I would slim
down these buttons. I tried but I can't find a spacer or so in Glade. Any idea?
Comment 11 Christoph Höger 2007-09-21 08:16:28 EDT
Well I'm not comfortable with glade too, but if you use 3 rows in the vbox this
may work.
Comment 12 Christoph Höger 2007-09-21 08:17:32 EDT
Created attachment 201971 [details]
glade file for properties page

New Layout
Comment 13 Dan Williams 2007-09-25 14:17:07 EDT
Instead of just not writing resolv.conf in 23_openvpn_workaround.patch, what
should happen here is to fall back to the orignal device's IP4Config and use the
composite of any returned settings from the VPN's IP4Config (maybe it passed
hostname but not DNS, or whatever) but when something is missing from the VPN's
IP4Config structure, fill that in with the original device's IP4Config data. 
The bits that write out resolv.conf are pretty fragile, and usually
short-circuiting them like this causes either one of (1) direct resolv.conf or
(2) caching nameserver to not work correctly.
Comment 14 Christoph Höger 2007-11-05 14:21:14 EST
What is the current state? Did someone write a patch for NM 0.7? What Dan argues
sounds correct to me, but i'm not quite sure, if I can dig deep enough into NM
logic.
Comment 15 Dan Williams 2008-05-05 17:10:50 EDT
This issue should be fixed in both 0.7 and 0.6.6; NM will fall back to the
highest stacked config that has DNS info.  0.6.6 is in F7-updates already.

Note You need to log in before you can comment on or make changes to this bug.