New NetworkManager breaks VPN DNS.
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| network-manager (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned | ||
Bug Description
Alright, this is going to be a frustrating bug for everyone involved I expect, but here goes.
On Ubuntu 16.04, using a non-released VPN client (making this _much_ harder for anyone to reproduce), upgrading the network-manager packages from 1.2.2-0ubuntu0.
And it broke it really oddly.
dnsmasq binds to socket 12 for the new interface, just fine.
strace shows that it does the sendto for the DNS request, and that the poll calls are working, just fine.
tcpdump shows the response messages, they are coming back from the correct host and port, going to my IP and the port that dnsmasq is sending from.
There are no iptables rules involved, nothing is set to deny.
dnsmasq is never getting the response packet.
The request thus times out.
Doing a host or dig directly to the DNS server works just fine.
And this is completely reproducible, and goes away the moment I downgrade back to 1.2.2-0ubuntu0.
Was there some change to how network-manager handles VPN interfaces/tap0 in the new version?
| Mercury (warp-spam-launchpad) wrote | #1 |
| Launchpad Janitor (janitor) wrote | #2 |
| Changed in network-manager (Ubuntu): | |
| status: | New → Confirmed |
| litinoveweedle (litinoveweedle) wrote | #3 |
Alright, this is due to a change to 1.2.4:
commit 2f12f485607590d
Author: Beniamino Galvani <email address hidden>
Date: Wed May 11 18:43:41 2016 +0200
dns: specify egress interface for each dnsmasq upstream server
Currently we don't specify to dnsmasq which interface must be used to
contact a given nameserver and so requests can be sent through the
wrong interface.
Fix this by concatenating a @interface prefix to each server (unless
an IPv6 interface scope-id is already present).
https:/
(cherry picked from commit b71e104d333a1eb
Now, this causes _two_ problems.
The first is that for some VPN connections you get traffic going out on tap0, but due to the wonders of ipsec the responses show up on the actual interface, such as eth0 or wlan0. This is a little bit of a pain normally, but it means that dnsmasq simply dies. It is possible that this is something I can fix on my VPN package, but it's _not_ a change that I expected to see in a LTS release.
Second, https:/
So, either 16.04 needs to fall back to 1.2.2, or dnsmasq needs the fix applied.
(And if the latter is chosen, VPN plugins which worked before may still be non-functional until additional work on them is done. Again, in an LTS release?)
Regards,
Zephaniah E. Loss-Cutler-Hull.