** Description changed: - * Impact + [Impact] + When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not - 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". - * Test case + 2) Connect to the VPN. - Configure the system to send all the traffic to a VPN, do a name - resolution, the request should not go to the public DNS server (to be - checked by capturing the traffic by example with wireshark) + 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 + [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!)
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
