[Bug 1754671] Re: Full-tunnel VPN DNS leakage regression

[dwmw2]

> That's weird, do you understand why? The update was deleted so you should be back to initial 
> situation, we had no change to the previous package build

Other package changes? Certainly systemd-resolver although we don't use
that (because of a previous VPN DNS leak problem) we use dnsmasq.

My original thought was that it was the VPN config change that we'd made
to cope with the new NM, but testing seems to show it isn't that.

Now we have a failure mode which some people had *occasionally* reported
before, where even VPN lookups which *must* go to the VPN, for the
company domain, are not. This was just occasional before; now it seems
to happen all the time. I haven't done a thorough investigation since
just putting the updated NM back has been enough to fix it.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1754671

Title:
  Full-tunnel VPN DNS leakage regression

Status in NetworkManager:
  Fix Released
Status in network-manager package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in network-manager source package in Xenial:
  New
Status in systemd source package in Xenial:
  Invalid
Status in network-manager source package in Bionic:
  In Progress
Status in systemd source package in Bionic:
  Fix Released
Status in network-manager source package in Cosmic:
  Won't Fix
Status in systemd source package in Cosmic:
  Fix Released

Bug description:
  [Impact]
  When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not

  [Test case]
  1) Set up a VPN with split tunneling:
    a) Configure VPN normally (set up remote host, any ports and options needed for the VPN to work)
    b) Under the IPv4 tab: enable "Use this connection only for the resources on its network".
    c) Under the IPv6 tab: enable "Use this connection only for the resources on its network".

  2) Connect to the VPN.

  3) Run 'systemd-resolve --status'; note the DNS servers configured:
    a) For the VPN; under a separate link (probably tun0), note down the IP of the DNS server(s). Also note the name of the interface (link).
    b) For the "main" connection; under the link for your ethernet or wireless devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). Also note the name of the interface (link).

  4) In a separate terminal, run 'sudo tcpdump -ni <the main interface>
  port 53'; let it run.

  5) In a separate terminal, run 'sudo tcpdump -ni <the VPN interface>
  port 53'; let it run.

  6) In yet another terminal, issue name resolution requests using dig:
    a) For a name known to be reachable via the public network:
       'dig www.yahoo.com'
    b) For a name known to be reachable only via the VPN:
       'dig <some DNS behind the VPN>'

  7) Check the output of each terminal running tcpdump. When requesting
  the public name, traffic can go through either. When requesting the
  "private" name (behind the VPN), traffic should only be going through
  the interface for the VPN. Additionally, ensure the IP receiving the
  requests for the VPN name is indeed the IP address noted above for the
  VPN's DNS server.

  If you see no traffic showing in tcpdump output when requesting a
  name, it may be because it is cached by systemd-resolved. Use a
  different name you have not tried before.

  
  [Regression potential]
  The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations

  -----------------

  In 16.04 the NetworkManager package used to carry this patch:
  http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch

  It fixed the DNS setup so that when I'm on the VPN, I am not sending
  unencrypted DNS queries to the (potentially hostile) local
  nameservers.

  This patch disappeared in an update. I think it was present in
  1.2.2-0ubuntu0.16.04.4 but was dropped some time later.

  This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422
  It's not a *regression* there though, as they didn't fix it yet (unfortunately!)

To manage notifications about this bug go to:
https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions