Lukas, thank you for the detailed information. However On Mon, Apr 24, 2017 at 9:33 AM, Lukas Dzunko <lu...@dzunko.sk> wrote: > Hello Paul. DNS leak mean that DNS queries still hit local DNS server > while VPN connection is active. DNS resolver should query only DNS > servers defined by VPN while connection is active.
You seemed to have ignored Paul's message and instead provided context which should go in a different bug. This bug was for name resolution failing after suspend/resume. It had nothing directly to do with VPNs. Please file a new bug. On Mon, Apr 24, 2017 at 9:33 AM, Lukas Dzunko <lu...@dzunko.sk> wrote: > Hello Paul. DNS leak mean that DNS queries still hit local DNS server > while VPN connection is active. DNS resolver should query only DNS > servers defined by VPN while connection is active. > > I did following test: > > - upgraded network-manager to 1.2.6-0ubuntu0.16.04.1 > (dnsmasq-base=2.75-1ubuntu0.16.04.2) > - restated my laptop to ensure clean start > - connected to VPN using openconnect / network-manager-openconnect-gnome > > Observed results -> DNS queries are forwarded only to DNS servers > defined by LAN connection (this is wrong / connection not working at > all) > > - "killall dnsmasq" > - dnsmasq get automatically restarted by system > > Observed results -> most of the the queries are forwarded to DNS servers > defined by VPN, but lot of queries get forwarded to DNS servers defined > by LAN connection (this is still wrong / DNS leaks, attacker can hijack > connection even if VPN is enabled) > > - I downgraded back to network-manager to 1.2.2-0ubuntu0.16.04.4 > (dnsmasq-base stay same) > - restated my laptop to ensure clean test > - connected to same VPN using openconnect > > Observed results -> DNS queries are forwarded only to DNS servers > defined by VPN connection. There are no leaks to LAN DNS server (this is > correct behavior). > > ============== > > DNS leaks are bad for several reasons. Most important ones are that it > provide visibility of host names to possibly un-trusted network and give > ability to hijack connection. When I connect to VPN server I expect that > all traffic hit only particular vpn server / gateway. If there is query > to "secure-company-server.example.com" and this hit DNS on LAN then we > are instantly leaking secured names. If LAN DNS server respond to this > (or response is spoofed) then connection will be made outside of VPN > environment. This effectively kill security of VPN connection ... > > ============== > > FYI: I am currently in environment where DHCP set DNS servers but policy > deny connection to them (don't ask why). Therefore is much more visible > if queries get forwarded to LAN DNS server just because they never get > responded ... this may be reason why some of folks here claim that fix > is working. If LAN DNS server respond with something then there is no > visibility of problem ... > > ============== > > FYI2: all tests for this update was monitored by wireshark. ... just to > not confuse with previous "fyi" comment > > ============== > > Lukas > > -- > You received this bug notification because you are a bug assignee. > https://bugs.launchpad.net/bugs/1639776 > > Title: > name resolution (dnsmasq) fails to send queries out after > suspend/resume reconnects the interface > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1639776/+subscriptions -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1639776 Title: name resolution (dnsmasq) fails to send queries out after suspend/resume reconnects the interface Status in dnsmasq package in Ubuntu: Fix Released Status in network-manager package in Ubuntu: Invalid Status in dnsmasq source package in Xenial: Fix Released Status in network-manager source package in Xenial: Invalid Status in dnsmasq source package in Yakkety: Fix Released Status in network-manager source package in Yakkety: Invalid Status in dnsmasq package in Debian: Fix Released Bug description: [Impact] * suspend/resume (which involves disconnection of network devices) leads to dnsmasq failures. [Test Case] * suspend/resume on 16.04 or 16.10 when using dnsmasq, and see failures upon resume. [Regression Potential] * The fix was NMU'd in Debian in the version immediately after 16.10's. I believe the regression potential is very low as this is a clear bug-fix from upstream. --- Failure is caused by ENODEV return for all dns queries like: sendto(11, "\232\325\1\0\0\1\0\0\0\0\0\0\4mail\6google\3com\0\0\1\0"..., 33, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("62.241.198.245")}, 16) = -1 ENODEV (No such device) Problem is reported and fixed: https://bugzilla.redhat.com/show_bug.cgi?id=1367772 http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=2675f2061525bc954be14988d64384b74aa7bf8b I didn't yet test if applying that patch to ubuntu package works. I will try the patch in a few hours. ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: dnsmasq-base 2.76-4 ProcVersionSignature: Ubuntu 4.8.0-26.28-generic 4.8.0 Uname: Linux 4.8.0-26-generic x86_64 ApportVersion: 2.20.3-0ubuntu8 Architecture: amd64 CurrentDesktop: GNOME Date: Mon Nov 7 14:11:51 2016 InstallationDate: Installed on 2037-12-25 (-7718 days ago) InstallationMedia: Lubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: dnsmasq UpgradeStatus: Upgraded to yakkety on 2016-10-21 (16 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1639776/+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
