On Tue, 2014-10-21 at 07:09 +0200, Olav Morken wrote: > On Mon, Oct 20, 2014 at 16:20:03 -0500, Dan Williams wrote: > > On Fri, 2014-10-10 at 21:17 +0200, Olav Morken wrote: > > > Hi, > > > > > > I am trying to set up Network Manager to connect to an OpenVPN server, > > > and have trouble understanding how it applies the DNS settings it > > > receives from the server. > > > > Sorry for the late reply... > > > > Which version of NM do you have, and what distro? > > It's XUbuntu 14.04 with network-manager 0.9.8.8-0ubuntu7 > > (I guess I should have been clearer about it being included at the end > of my original message :) ) > > > > Basically, as far as I can tell, it automatically assumes that I want > > > to use split dns, and limits the DNS servers it receives from the > > > OpenVPN servers to the domains it assumes "belongs to" this > > > configuration. However, it also ignores the existing DNS servers it > > > has configured. > > > > By default, NM will not do split DNS, which means when the VPN is > > connected, the VPN nameservers replace the existing nameservers. This > > is required to ensure that if for some reason the VPN nameservers cannot > > be contacted, that your queries don't fall back to the non-VPN > > nameservers and return bogus (and potentially malicious) results. > > > > But, if you add "dns=dnsmasq" to > > the /etc/NetworkManager/NetworkManager.conf file and install 'dnsmasq', > > then NM will run in split DNS mode. Here, NM will spawn a private copy > > of dnsmasq and send it configuration to direct any queries ending in the > > domain passed back from the openvpn server (or entered into the NM > > configuration for that VPN connection) to the VPN nameservers, and > > everything else to the non-VPN nameservers. > > That is quite a large change in behavior for someone running with > dnsmasq. I also think it is the wrong behavior when we are pushing a > default route over the VPN. With a default route over the VPN it is > likely that we would want all traffic, including DNS traffic over the > VPN. It is also likely that the user would end up trying to contact > the local DNS servers over the VPN, which would break.
If you want everything to go to the VPN nameservers, then 'dns=dnsmasq' isn't what you want, since that is what enables this local caching nameserver configuration. I guess you just want the non-local-caching configuration, where you can just not specify "dns=". > > > That leaves us with a dnsmasq configured with two nameservers it will > > > query for two specific subdomains, and no nameservers it will use for > > > other domains. The result is that dnsmasq is only willing to respond > > > to DNS queries for those subdomains, and respond with "REFUSED" for > > > every other domain. > > > > > > I assume that this is not the way it is supposed to work, since that > > > would mean that everyone connecting to a VPN would be unable to access > > > most of the Internet. I therefore assume that there is something wrong > > > with my configuration. > > > > That sounds like a bug; do you know if you have any custom dnsmasq > > configuration on that system? Also check two thigns: > > > > 1) /etc/resolv.conf should have "127.0.0.1" as the only namesever > > 2) Look in /var/run/NetworkManager (or /run/NetworkManager) for the > > 'dnsmasq.conf' file which is what NM sends to dnsmasq > > > > (the only caveat here is that if you run Ubuntu, this procedure may not > > apply as the info is sent to dnsmasq over D-Bus) > > I wasn't aware the Ubuntu had such significant changes to Network > Manager. In that case, I think the behavior we am seeing is > Ubuntu-specific. > > There is no customization of the dnsmasq settings on this system. (In > fact the behavior has been observed on several different Ubuntu > installations.) > > From the logs (included at the end of my original message): > > dnsmasq[1464]: setting upstream servers from DBus > dnsmasq[1464]: using nameserver 198.51.100.168#53 for domain > 0.192.in-addr.arpa > dnsmasq[1464]: using nameserver 198.51.100.168#53 for domain example.org > dnsmasq[1464]: using nameserver 198.51.100.57#53 for domain > 0.192.in-addr.arpa > dnsmasq[1464]: using nameserver 198.51.100.57#53 for domain example.org > > Nothing in the log about the original (non-VPN) DNS servers, so I am > guessing they were removed. I think with Ubuntu, dns=dnsmasq might be enabled by default. Can you check /etc/NetworkManager/NetworkManager.conf and if so, remove that line? > > Let us know what the results are! > > For what it is worth, after futher testing we have determined that it > is the IPv6 configuration that "breaks" the DNS config. We have seen > three different behaviors, depending on the VPN config: > > 1. VPN with only IPv4 address and default route: > > The DNS servers are added as global DNS servers. > > 2. VPN with both IPv4 and IPV6 addresses and default routes, but only > IPv4 DNS servers pushed through VPN configuration: > > The DNS servers are added as local DNS servers, with no "global" > DNS servers. > > 3. VPN with both IPv4 and IPV6 addresses and default routes, and both > IPv4 and IPv6 DNS servers pushed through VPN configuration: > > The IPv4 DNS servers are added as "local" DNS servers, and one of > the IPv6 DNS servers are added as a "global" DNS server. > > It was scenario 2 that was the original problem. For now, it looks > like we have a workaround in scenario 3, since in that case we are > left with a IPv6 DNS server that can be used for global queries. > > A wild guess from me is that the Ubuntu devlopers noticed the broken > VPN DNS behavior with dnsmasq (since dnsmasq is the default on > Ubuntu), and fixed it for the IPv4-only VPN case, but forgot to handle > the IPv4-and-IPv6 case. > > I think I'll try to raise it as a Ubuntu-bug, and live with pushing an > IPv6 DNS server as a workaround. Odd... I'm not quite sure why it would be happening that way. In any case, NM should only be doing split DNS when 'dns=dnsmasq' is set *and* the VPN sends a domain name to NetworkManager. So I'd expect to see your #1 case above also do "local" VPN DNS servers, with the DHCP servers as fallback. Dan _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
