I've filled the bug under NM since the bug report on
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):
100% reproducible on an openvpn vpn where the server doesnt push DNS servers to
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
resolv.conf containing no DNS servers
resolv.conf should retain the DNS servers, since we're not redirecting the gateway.
I can absolutely reproduce this bug.
Can someone provide a testpackage with the patch?
*** Bug 253438 has been marked as a duplicate of this bug. ***
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.
The patch above needs NM to be patched with
to work properly.
So if this is not already in upstream I would suggest to add it ASAP.
I'm going to give it a try tonight.
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.
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
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
Do you need any more input (modified patch or something)?
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
Please use this one when you try.
looks perfect. Thank you.
btw: you _could_ slim down the buttons in the TLS-Auth section a little bit ;)
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?
Well I'm not comfortable with glade too, but if you use 3 rows in the vbox this
Created attachment 201971 [details]
glade file for properties page
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.
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
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.