My employer requires me to run a full-tunnel VPN. This is fairly common practice; I am required to use the VPN for *all* IP traffic, as if it was the 20th century and I had dialled into the corporate modem bank. Policy requires that I don't even have routes to my local network. Since https://bugzilla.gnome.org/show_bug.cgi?id=767288 is not yet implemented in NM, they achieve that with a NM dispatcher script to update the routing tables. (This is background information; this part is working OK although it would be *nice* to have it properly supported without the hackish script.) However, NetworkManager is misconfiguring the DNS. Even when it's on a full-tunnel VPN it's still attempting to talk to the local nameservers on the physical network for some lookups. Once on the full-tunnel VPN, it should never use them at all. This is both a functional problem, and a security problem. It's a functional problem because some domains get *different* results when looked up internally. This split-horizon "schizo-DNS" is a heinous crime, but unfortunately common. And it's not just "company.com" which is actually in my default "append to failing queries and try this before eventually failing" search domain for the VPN, but all kinds of other subsidiary names and "company-corp.com". I also want to get the *correct* GeoDNS results for the place my traffic is going to emerge onto the Internet, not a local GeoDNS result leads to worse routing. It's a security problem because when I'm on a full-tunnel VPN I should *never* leak information about what I'm looking up, to potentially hostile local DNS servers. This is supposed to be like dial-up directly into the company network. That is the expectation, and to do otherwise is very wrong.
Reading that back, I'm not sure why I even mentioned the routing trick to stop access to the local network. That's just how I *noticed* this problem, of course, because those insecure attempts to reach the local network were rightly prevented.
Ubuntu used to have a patch which fixed this, but dropped it: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch
On Fedora the default configuration is dns=default, which means that NM updates resolv.conf directly. With this configuration, if you connect to a full-tunnel VPN, resolv.conf will be updated to have the VPN name server as first entry and the local name server after. This guarantees that DNS queries go through the VPN; only when the VPN name server is not reachable the local server is contacted. Since this can be harmful in some situations (but there are cases when this is useful), it is possible to set ipv4.dns-priority=-1 for the VPN so that only the VPN name server get added to resolv.conf. With this configuration there is no leak of DNS queries to local servers. If you change the default configuration and set dns=dnsmasq, then NM enables split-dns and uses the VPN name server only for the domains in the VPN search list, even if the VPN gets the default route. This is suboptimal and probably can be fixed introducing a new variable (perhaps "dns.lookup-priority" ?), that indicates which connections should be used for DNS queries not matching any lookup domain. The default value (0, "auto"), should prioritize first full-tunnel VPNs and then non-VPN connections. But I'll send a more detailed explanation on the upstream bugzilla.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Hi, was this ever fixed?
Yes, this was fixed in NM 1.12 (Fedora 29).