Re: VPN + dnsmasq = split dns?
- From: Dan Williams <dcbw redhat com>
- To: networkmanager-list gnome org
- Subject: Re: VPN + dnsmasq = split dns?
- Date: Wed, 22 Oct 2014 13:54:32 -0500
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]