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.
I can absolutely reproduce this bug. Can someone provide a testpackage with the patch? regards christoph
*** 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 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.
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 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)?
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.
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 may work.
Created attachment 201971 [details] glade file for properties page New Layout
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 logic.
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.