I have now done the test under [Test Case] in the initial description of
this bug report.
I have a completely updated (including -proposed) Bionic machine (real
iron, a Lenovo X1 Carbon 2nd gen from 2015) with network-manager
1.10.14-0ubuntu1
I have configured the Canonical VPN, both UK and US. I have turned on
only the UK one. It is configured to be used only for the internal
destinations on both IPv4 and IPv6.
The system in this configuration I have rebooted to be assure that all
processes including the kernel are using the newest software.
Then I have followed the instructions of the test case.
When running "dig <a Canonical-internal host name>" I get immediately an
answer with exit code 0 ("echo $?"), so the request was successful.
When I look into the "tcpdump" terminals, the host name gets polled
through both interfaces, but naturally the answer only comes from the
DNS of the VPN.
So to my understanding the bug is not fixed as the private host name
gets also sent to the public DNS.
"systemd-resolve --status" lists the VPN DNS first, as link 4 and
afterwards the public DNS as link3.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager 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 network-manager source package in Bionic:
Fix Committed
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
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
