Ubuntu
network-manager package

Wrong dnsmasq configuration when VPN is set as default gateway

Bug #898224 reported by Stéphane Graber
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Fix Released
High
Mathieu Trudel-Lapierre

Bug Description

When using dnsmasq with Network Manager (DNS=dnsmasq in the config) and a VPN that's not configured as "Use VPN only for resources on its network" (default configuration), the dnsmasq configuration ends up being wrong.

I'd have expected the default DNS server to be the one received from the VPN connection instead of the one from the current wired/wireless network as that one isn't reachable.

So in a setup where VPN doesn't provide the default gateway, DNS should be:
 - DNS queries for anything on the VPN network => DNS server from VPN
 - Everything elsse => DNS server from current wired/wireless network

In a setup where the default gateway is the VPN
 - Everything => DNS server from VPN

Mathieu Trudel-Lapierre (cyphermox)
Changed in network-manager (Ubuntu):
status: New → Triaged
importance: Undecided → High
Mathieu Trudel-Lapierre (cyphermox)
Changed in network-manager (Ubuntu):
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
Mathieu Trudel-Lapierre (cyphermox)
Changed in network-manager (Ubuntu):
status: Triaged → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package network-manager - 0.9.2.0+git201201101813.0b30200-0ubuntu1

---------------
network-manager (0.9.2.0+git201201101813.0b30200-0ubuntu1) precise; urgency=low

  * New upstream snapshot.
  * debian/libnm-util2.symbols: add new symbols:
    - nm_setting_vpn_get_num_data_items@Base
    - nm_setting_vpn_get_num_secrets@Base
  * debian/patches/dnsmasq-vpn-dns-filtering.patch: filter nameservers before
    adding to dnsmasq to avoid using DNS servers which are unavailable due to
    a VPN taking the default route, or to be considered insecure when a VPN
    is connected. (LP: #898224)
  * debian/NetworkManager.conf: enable the use of DNSMasq as a resolver by
    default, NetworkManager will configure it based on DHCP responses and
    interface settings. See the 'foundations-p-dns-resolving' blueprint.
  * debian/control: move dnsmasq-base from a Recommends to a Depends.
 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 12 Jan 2012 11:01:32 +0100

Changed in network-manager (Ubuntu):
status: In Progress → Fix Released
Revision history for this message
markdv77 (markdv77) wrote :

WHOOT!!! I've been waiting for this for soooo long. Can't watit to give this a go, Nice job!! :)
Any chance getting this (backported) into an earlier release? The Porelain Pot - or whatever it's name is - is still so far away...

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

No, this won't be backported or SRU'd to earlier releases. If you feel daring, you may wish to try out Precise Pangolin early, and help with the testing... see here: http://www.ubuntu.com/testing

Since Alpha 1 is the only milestone released so far, you'll need to make sure to update to the latest packages too; which may prove to be complicated for testing without installing on your system (but you can still install on a virtual machine or so).

Revision history for this message
jm (joao-t-martins) wrote :

This still happens on network-manager 0.9.4 on precise pangolin... the dnsmasq configuration isn't set to "all servers", so dnsmasq picks the original one outside the VPN, making hosts inside the VPN inaccessible.

Revision history for this message
Andrew Selder (aselder) wrote :

This still appears to be a problem on Ubuntu 12.10 with NetworkManager 0.9.6.0

I can connect to the VPN fine and access assets by IP address, but I can't resolve any internal names..

For full details included log output see: http://ubuntuforums.org/showthread.php?p=12534460

Revision history for this message
Ryan Novosielski (novosirj) wrote :

I'm still seeing this on 0.9.8.0. Are we sure this is fixed?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.