DNS server from vpn connection is not being used after network-manager upgrade to 1.2.6-0ubuntu0.16.04.1

[stan383]

I use my company's cisco vpn via network-manager in Ubuntu 16.04.2 LTS. After recent upgrade of network-manager:amd64 from version 1.2.2-0ubuntu0.16.04.4 to version 1.2.6-0ubuntu0.16.04.1 DNS resolution of VPN's server hostnames does not work. Roll back to version 1.2.2-0ubuntu0.16.04.4 solves the problem.

Steps for reproducing:
1. upgrade network-manager:amd64 from version 1.2.2-0ubuntu0.16.04.4 to version 1.2.6-0ubuntu0.16.04.1
2. connect to VPN via network-manager applet
3. nslookop servername.internal --> ** server can't find servername.internal: NXDOMAIN
4. disconnect from VPN via network-manager applet
5. roll back network-manager via command: sudo apt-get install network-manager=1.2.2-0ubuntu0.16.04.4
6. restart network-manager via sudo service network-manager restart
7. connect to VPN via network-manager applet
8. nslookop servername.internal --> the server is resolved correctly

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: network-manager 1.2.6-0ubuntu0.16.04.1
ProcVersionSignature: Ubuntu 4.4.0-66.87-generic 4.4.44
Uname: Linux 4.4.0-66-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.5
Architecture: amd64
CurrentDesktop: Unity
Date: Thu Mar 9 19:49:55 2017
InstallationDate: Installed on 2015-10-05 (520 days ago)
InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422)
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
 WimaxEnabled=true
SourcePackage: network-manager
UpgradeStatus: No upgrade log present (probably fresh install)
nmcli-nm:
 RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN
 running 1.2.6 connected started full enabled enabled enabled enabled enabled

[Refefer (refefer)]

I can confirm the exact same behavior.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[ALinuxUser (buntulongername-new)]

This bug appears to be a duplicate of #167196; can the two reports - and their 'heat' - be merged?

[psylem (subnetjet)]

Manually specifying the DNS servers in the connection doesn't seem to help. I was able to work around this by commenting out dnsmasq in /etc/NetworkManager/NetworkManager.conf

Maybe that's a clue as to the cause?

[dlotton (yellow56)]

network-manager:amd64 (1.2.2-0ubuntu0.16.04.4, 1.2.6-0ubuntu0.16.04.1)

I'm seeing a very similar problem, except I'm using a PPTP tunnel. I'm on a Mint MATE 18.1 distro. On approximately 3/8/2017 the network manager package was updated and about that time is when name resolution stopped working when connected to a PPTP tunnel.

I can see that the ppp0 interface is getting a DHCP address from the remote end, and it is also receiving a DNS IP address for the remote network. That information gets populated into 'etc/ppp/resolv.conf' and the timestamp for that file corresponds to the date/time I establish the PPTP connection.

I am able to reach machines on the remote network by IP address. This worked as of last week (approx 3/8/2017) and had been working for a year or more prior.

I'm not sure how the local resolver stuff works, but it seems like the proper information is being retrieved from the remote end point (IP address, DNS info, etc.), but the local resolver is not pulling in the information.

[dlotton (yellow56)]

It looks like the resolvconf package was updated on my machine on 3/2/2017 also. Isn't resolvconf responsible for updating DNS info when something like a DNS lease is obtained?

I'm pretty sure I didn't see the problem until after the network-manager package was updated around 3/8/2017, but maybe there was cached information that allowed it to continue to work for a while. I'm not sure how all of this plays together.

[dlotton (yellow56)]

More input...

I downgraded the network manager from 1.2.6-0ubuntu0.16.04.1 to 1.2.2-0ubuntu0.16.04.4. Oddly, name resolution seemed to work for a few minutes, then resumed the previous behavior where it would use the dhcp specified DNS.

I downgraded resolvconf from 1.78ubuntu4 to 1.78ubuntu2. So far this seems to be a sticky fix. So far still resolving names from remote DNS.

[dlotton (yellow56)]

I've done some additional testing and it seems as though both the network manager and the resolvconf package need to be downgraded to get to a working state. If either or both are at the latest revision (resolvconf = 1.78ubuntu4 and/or network-manager = 1.2.6-0ubuntu0.16.04.1) name resolution through the DNS specified by the DHCP information for my PPTP tunnel (interface ppp0) doesn't work.

In some instances when one or both packages were at the latest revision name resolution worked properly for a few minutes, then broke.

The only stable working configuration I've found is having BOTH packages downgraded (resolvconf = 1.78ubuntu2 *AND* network-manager = 1.2.2-0ubuntu0.16.04.4).

Hope this is helpful.

DL

[Orange Shiang-Yuan Kao (orange-kao)]

I have the similar issue, but I'm using OpenVPN and the symptom is slightly different.

With OpenVPN, the name resolution is normal on the first attempt to connect VPN (after reboot). However, by disconnect and connect VPN again, the name resolution will be broken. As below.

== Reproduce steps ==
1. Reboot system
2. Connect to OpenVPN gateway
3. Issue command "host server.mydomain.com" -> success
   DNS request & response can be seen by sniffing (Wireshark) tun0 interface
4. Disconnect VPN
5. Connect to OpenVPN gateway
6. Issue command "host server.mydomain.com" -> Host server.mydomain.com not found: 5(REFUSED)
   DNS request & response can NOT be seen on tun0 nor ens33 interface

Note A: After step 6, DNS resolution will NOT back to normal unless reboot or "sudo service network-manager restart".

Note B: After step 6, logout and login will NOT make it back to normal.

Note C: After step 6, issue command "host server.mydomain.com 192.168.3.74" -> success, assume 192.168.3.74 is the DNS server behind VPN gateway
DNS request & response can be seen on tun0 interface

== Package information ==
libnma-common 1.2.6-0ubuntu0.16.04.2
libnma0:amd64 1.2.6-0ubuntu0.16.04.2
network-manager 1.2.6-0ubuntu0.16.04.1
network-manager-gnome 1.2.6-0ubuntu0.16.04.2
network-manager-openvpn 1.1.93-1ubuntu1.1
network-manager-openvpn-gnome 1.1.93-1ubuntu1.1
network-manager-pptp 1.1.93-1ubuntu1
network-manager-pptp-gnome 1.1.93-1ubuntu1
resolvconf 1.78ubuntu4

It will became NOT reproducible after downgrading
network-manager 1.2.2-0ubuntu0.16.04.3

OS version:
Ubuntu Desktop 16.04.2 LTS amd64

This test is conducted under virtual machine environment to minimise uncontrollable factors.

[Captaine74 (benoitpourre)]

Same issue with OpenVPN. As a workaround, once the VPN is connected, I edit /etc/resolv.conf and add my DNS (nameserver 8.8.8.8).

It makes DNS resolution work again. But if I disconnect and reconnect the VPN resolv.conf is indeed reseted.

I tried to force my DNS in the VPN settings in the network manager but no improvement.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Lukas Dzunko (lukas-d)]

Same issue with openconnect (cisco) and OpenVPN on 16.04.2 LTS. Connection is established but:

- DNS is not working
- Disconnect VPN button is missing
- Configure VPN is grayed out and not working.

Please either increase priority or allow full downgrade of network manager. Downgrading "network-manager" from 1.2.6-0ubuntu0.16.04.1 to 1.2.2-0ubuntu0.16.04.4 partly resolved problem. DNS is working but GUI is still missing buttons. I assume we need to downgrade also "network-manager-gnome" which no longer have 1.2.2-* version in repository. Why it was removed on day this update was rolled out ?!

(I am using LTS version of Ubuntu on my work computer and now I am starting to think if this was good choise ... VPN not working for almost month is not acceptable)

Lukas

[Mercury (warp-spam-launchpad)]

After two and a half weeks, can we please get a build of resolvconf with http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=2675f2061525bc954be14988d64384b74aa7bf8b applied pushed out?

We don't even need the full new release of resolvconf, we just need the documented bug (https://bugzilla.redhat.com/show_bug.cgi?id=1373485) patched.

This was covered in detail in https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1672491 and while it won't fix some of my use cases, it will at least get a large number of the VPN users working again.

Regards,
Zephaniah E. Loss-Cutler-Hull.

[Goth Queen (artistbraab)]

This bug also affects our boxes that have network-manager 1.2.6-0ubuntu0.16.0 amd64. Can confirm that one of our boxes, which is still on 14.04 LTS, and has network-manager 0.9.8.8-0ubuntu7.3 amd64 does not have these issues.

In our case, we noticed that, when VPN is active, network-manager refuses to use the DNS servers defined by the VPN (openVPN). In stead, network-manager defaults to the "normal", "local" DNS server.
This means a DNS leak, since the original (ISP) DNS can be seen.

A workaround is setting 'Automatic (DHCP) addresses only" under IPv4 Settings in network-manager for the default network connection. This means however that, when no VPN, but the default net connection is used, network-manager has no DNS server, because this has to be entered manually in the DNS Servers field.

[rooijan (rrossouw)]

Maybe if helpful to someone else quickest way for me to work around it is kill the dnsmasq process. When it restarts itself DNS over VPN is working.

[andi bachmann (bachmann)]

@rooijan : killing the `dnsmasq` process (#16) after connecting to the VPN works for me (network-manager 1.2.6-0ubunt amd64 on 16.04 lts ).

[Nicholas Stommel (nstommel)]

I have downgraded both the network-manager and resolvconf package but I still experience complete DNS resolution failure randomly, where restarting the network manager has no effect and I cannot connect to the internet. The only way to get DNS working again is to completely reboot the computer, which is a massive pain and shouldn't happen. I need openvpn to connect to my university's ssh server at home. LTS was working totally fine for me for months but now I have run into this massively annoying issue. Killing the dnsmasq process has no effect for me.
Downgrading the two packages makes it so that my vpn connection *sometimes* works but without fail, I eventually have to force restart my computer to connect to the internet at all. This is intolerable.

[Ryan Harper (raharper)]

The change introduced[1] in resolveconf-1.78ubuntu4 over 1.78ubuntu2 affects *when* resolvconf service starts; but does not affect the runtime code and is not involved in any of the runtime action of the resolvconf service. I'm marking the resolvconf task as invalid.

If you feel that the resolvconf change to when resolvconf service starts during boot affects the runtime DNS settings, please do re-open against resolvconf and include:
a. systemctl status resolvconf
b. contents of /etc/resolv.conf

1. diff -Nru resolvconf-1.78ubuntu2/debian/resolvconf.service resolvconf-1.78ubuntu4/debian/resolvconf.service
--- resolvconf-1.78ubuntu2/debian/resolvconf.service 2015-06-03 15:58:21.000000000 -0500
+++ resolvconf-1.78ubuntu4/debian/resolvconf.service 2016-12-07 03:03:18.000000000 -0600
@@ -2,7 +2,8 @@
 Description=Nameserver information manager
 Documentation=man:resolvconf(8)
 DefaultDependencies=no
-Before=networking.service
+Before=network-pre.target
+Wants=network-pre.target

[Mercury (warp-spam-launchpad)]

Ryan,

The problem is not that a recent change in resolvconf caused a regression.

The problem with resolvconf is that the upgrade to network-manager exposed an existing bug in resolvconf.

This happens because the new version of network-manager now tells resolvconf that it must only use a specific interface when talking to the name server, and resolvconf was not properly tracking how interfaces were added and removed from the system.

This is most obvious for VPN connections which use an interface for VPN traffic, as that interface will be destroyed and recreated on every VPN connection, triggering the bug in resolvconf. (Setting up the new DNS for the new VPN interface is insufficient to make it happy.)

This can also be triggered on systems that remove and readd interfaces for things like suspend or hibernate.

Redhat documented the bug fairly well when they found it, their bug report on the matter is https://bugzilla.redhat.com/show_bug.cgi?id=1373485

The actual patch that needs to be applied is git commit 2675f2061525bc954be14988d64384b74aa7bf8b, and the upstream gitweb URL for viewing the diff is: http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=2675f2061525bc954be14988d64384b74aa7bf8b

There is a separate (but very related) issue, in that some existing VPNs that involve ipsec have one interface for sending traffic and to hold an IP, but the response traffic appears on the interface of the primary internet connection. This is completely broken in the middle of an LTS by this change, and fixing the bug in resolvconf won't help. I'm still trying to sort out the right answer for some of my VPN use cases there.

[Ryan Harper (raharper)]

@Mercury

Hi, please note that the change I've made is *only* against the resolvconf task; as you say and document the issue (and potential fix) is against dnsmasq; ergo there is no need for a resolvconf patch/change.

You mention:

"and resolvconf was not properly tracking how interfaces were added and removed from the system."

I see no details or data in this bug, nor the RH bugzilla that indicates that resolvconf itself has an issue. If you have
more information on this, then please do add that;

Specifically to the recent upgrade to resolvconf (I included the diff of change); there is no runtime code change; only a systemd unit change on when the service is started. Even if there is some bug in resolvconf as you say; it will occur in the previous version and the updated version since the update did not modify any of the resolvconf runtime code.

If you believe that the *unit* change to resolvconf in 1.78ubuntu4 is related to this issue, please add that specific information before reopening the resolvconf task.

Finally, it does appear that there should be a dnsmasq task; I'll nominate that.

[Nicholas Stommel (nstommel)]

Okay so since resolvconf and dmasq are not cooperating, I have resorted to using dnscrypt-proxy. Credit to QkiZ, the dnscrypt-proxy service works EVERY TIME and ignores the (completely broken) DNS resolution of dnsmasq and resolvconf. Even with the newest version of network-manager (1.2.6) on 16.04 LTS and all its dependencies:
 network-manager
 libnm-glib-vpn1
 libnm-glib4
 libnm0
 libnm-util2
No more DNS resolution issues!
To apply this workaround (which actually also offers some security benefits against DNS leakage), use:
sudo apt install dnscrypt-proxy
In the network manager, select "Edit Connections", select the primary (non-VPN) network you use, click on the "IPv4 Settings" tab, change the "Method" tab to "Automatic (DHCP) addresses only", then add 127.0.0.2 to the "DNS servers:" box. Save your changes, then restart the connection by disabling and enabling networking. Now go to https://www.opendns.com/welcome/ and you should see a nice check mark.
Now, your network connection and VPN should work (meaning DNS resolution won't break on you) every single time you wake up from suspend or use
sudo service network-manager restart
And if for some odd reason it's slow just restart the network manager repeatedly by aliasing that to something like
alias nm-restart='sudo service network-manager restart'
in your ~/.bash_aliases file. I know, annoying but at least DNS resolution actually works and the computer doesn't have to be literally restarted to connect to the internet.
This isn't intended to be a fix, just a possible alternative for those of us who experience total DNS resolution failure using a vpn on Ubuntu.

[Nicholas Stommel (nstommel)]

Oops, Goth Queen actually provided a solution earlier, it was just difficult for me to understand at the time. Enter whatever fixed DNS server you want and
set 'Automatic (DHCP) addresses only' under IPv4 Settings in network-manager for the default network connection. So just manually entering in your VPN's DNS server (for PIA it's 209.222.18.222) or installing dnscrypt-proxy and choosing 127.0.0.2 as the server both work. This seems an adequate workaround for now.

[Nicholas Stommel (nstommel)]

Well, scratch that hope and consider me mistaken about Goth Queen's workaround. It appears that manually setting a fixed DNS server DOES allow for successful reconnect when the network manager is restarted (whereas before it wouldn't reconnect period), but just like this bug https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1631241 name resolution (not using the dnscrypt-proxy service, just a fixed DNS address) fails after waking up from suspend for some frustrating, arcane reason. I have downgraded the following packages:
(credit to Kostadin Stoilov)
sudo apt install network-manager=1.2.2-0ubuntu0.16.04.4
sudo apt install libnm-glib-vpn1=1.2.2-0ubuntu0.16.04.4
sudo apt install libnm-glib4=1.2.2-0ubuntu0.16.04.4
sudo apt install libnm0=1.2.2-0ubuntu0.16.04.4
sudo apt install libnm-util2=1.2.2-0ubuntu0.16.04.4
sudo apt install resolvconf=1.78ubuntu2

and held them in place with 'sudo apt-mark hold' for the time being, as there appears to be a critical flaw in the updated versions of network-manager and possibly resolv-conf and dnsmasq. I suppose we just have to wait until something is fixed.

[Nicholas Stommel (nstommel)]

Okay so I have found the issue pertaining to dns resolution on Ubuntu 16.04.2! There is a critical bug in the package dnsmasq-base here: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1639776
The fix hasn't yet been applied to the current version of dnsmasq-base.

This time I have all the dependencies on 1.2.6 at their newest version and installing the patched .deb version provided by Harald Rudell fixes DNS name resolution on wakeup/suspend and with restart of the network manager, all while cooperating with openvpn. I hope this helps anyone on 16.04.2 LTS!

wget https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1639776/+attachment/4780245/+files/dnsmasq-base_2.76-4ubuntu1FIX1639776ubuntu1_amd64.deb
sudo dpkg -i dnsmasq-base_2.76-4ubuntu1FIX1639776ubuntu1_amd64.deb

This appears to have actually worked, and is much better than using dnscrypt-proxy (which I have found to be incredibly slow) or holding back a bunch of packages.

[jaybo (ubuntu-one-ostaffe)]

My work around was deleting the etc/resolv.conf symbolic link and creating a resolv.conf file with DNS servers of my choice.

However, as mentioned in #13, Disconnect VPN button is missing and Configure VPN is grayed out and not working.

[ALinuxUser (buntulongername-new)]

Nicholas Stommel (nstommel): your fix didn't work for me. I think I had the newer version of dnsmasq already, from my distro's repositories, and Network-Manager 1.2.6 still - even after installing the patched version of dnsmasq you supplied - would not work with my VPN. I had to restore Network-Manager 1.2.2. Again.

[ALinuxUser (buntulongername-new)]

. . and now I can't remove your patched version of dnsmasq-base:

===========================
# apt remove dnsmasq-base
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  cinnamon-common cinnamon-control-center cinnamon-control-center-data cinnamon-l10n
  libandroid-properties1 libcinnamon-control-center1 libcinnamon-menu-3-0 libhardware2
  libhybris libhybris-common1 libmedia1 libndp0 libqofono-qt5-0 libqt5xmlpatterns5 streamer
  ubuntu-mobile-icons urfkill xawtv-plugins
Use 'apt autoremove' to remove them.
The following packages will be REMOVED
  cinnamon dnsmasq dnsmasq-base indicator-network mint-meta-cinnamon network-manager
  network-manager-gnome tlp-rdw
===========================

Nor does apt or synaptic seem to allow me to reinstall (as against remove) dnsmasq-base

I found a webpage that might be able to help (https://askubuntu.com/questions/17745/how-to-remove-a-deb-without-removing-its-dependencies) but I am worried about borking my system (and certainly I don't want to let apt remove all those packages).

[Lukas Dzunko (lukas-d)]

This bug is marked as duplicate to #1639776 but I think it is not 100% correct.

I recently updated all packages to latest version and VPN connection is still not working. Proposed update from #1639776 (dnsmasq-base=2.75-1ubuntu0.16.04.2) is not changing behavior. DNS queries are still forwarded to local DNS server instead of one defined by VPN after applying this update. When I downgrade network-manager to 1.2.2-0ubuntu0.16.04.4 problem immediately disappear:

network-manager:

1.2.2-0ubuntu0.16.04.4 -> DNS queries are forwared to DNS servers defined by VPN. Everything works fine

1.2.6-0ubuntu0.16.04.1 -> DNS queries are send to local DNS server only defectively making VPN connection to fail

I tried different commands like ping, host, systemd-resolve and all provide +- same result. Also GUI application (like browser) behave same. Therefore I think this is more problem with network-manager rather that dnsmasq-base.

[Lukas Dzunko (lukas-d)]

Reopened as #1688018 ... it was requested in #1639776 ... just FYI to people finding this one.

[Dez (rouniy)]

Still not fixed.

So when I lock package version of the:
network-manager (1.2.2-0ubuntu0.16.04.4)
network-manager-openvpn (1.1.93-1ubuntu1)
network-manager-openvpn-gnome (1.1.93-1ubuntu1)

It works again

[dlotton (yellow56)]

Just did a fresh install of Mint Mate 18.2 onto a new machine. Same problem exists. While connected to VPN DNS queries are leaking to non-VPN interface.

This needs to be fixed!

[M.Witte (m-witte-d)]

Still not fixed.

Same as @rouniy:

When I lock package version:
sudo apt install network-manager=1.2.2-0ubuntu0.16.04.4
sudo apt install libnm-glib-vpn1=1.2.2-0ubuntu0.16.04.4
sudo apt install libnm-glib4=1.2.2-0ubuntu0.16.04.4
sudo apt install libnm0=1.2.2-0ubuntu0.16.04.4
sudo apt install libnm-util2=1.2.2-0ubuntu0.16.04.4
sudo apt install resolvconf=1.78ubuntu2
sudo apt-mark hold network-manager
sudo apt-mark hold libnm-glib-vpn1
sudo apt-mark hold libnm-glib4
sudo apt-mark hold libnm0
sudo apt-mark hold libnm-util2
sudo apt-mark hold resolvconf

It works again.

[Jens Greifenhagen (jgreifenhagen)]

@rouniy @m-witte-d

Hi,

locking down the packages resulted in breaking gdm3 in my installation of ubuntu-gnome 16.04.4.
That's because gdm3 has a inherited dependency on libnm0 (>= 1.2.6-0ubuntu0.16.04.2) from gir1.2-networkmanager-1.0.

It might work going down the dependencies and lock down even more packages, but I don't have a good feeling when locking down more and more packages.

BTW: I am using network-manager-openconnect and network-manager-openconnect-gnome both in version 1.2.0-0ubuntu0.16.04.1. And the "killall dnsmasq" gets the system back into working order, but e.g. KVM NAT network connections are having issues as dnsmasq is used for that setup.

[Tony Kitzky (tkitzky)]

I am affected by this bug as well.

  * Ubuntu Xenial 16.04 AMD64 w most recent patches
  * network-manager 1.2.6-0ubuntu0.16.04.2
  * dnsmasq 2.75-1ubuntu0.16.04.4

Goth Queen's comment in post # 15 resolved my issue. (pun intended. thanks!)

[ghomem (gustavo)]

This is still not fixed and package 1.2.2-0ubuntu0.16.04.4 has disappeared from the mirrors :(

[Jason Sharpe (deltacloudnine)]

This is the *nastiest* bug I've ever encountered in the wild on my own in Linux (that has no good solution after this long). Package 1.2.2-0ubuntu0.16.04.4 has disappeared from the mirrors for Xenial (not that anyone should expect a normal user to go through the deep dive that is this subject, once one realizes what is happening). The cipher in use by AWS for Client VPN isn't available in OpenSSL within Trusty Tahr, so running an old Ubuntu distro is also not a viable solution for me. This is about as serious of a bug as I could think of, and we're almost two years in without it being addressed. Hate to be tin-foil-hatty, but this seems like the kind of thing that gets put into software as a result of government-agency interests. How many people around the world expecting their VPN to protect them while viewing content from outside of their nation state are DNS-leaking all over the place to their local ISP? How many companies are leaking private zone DNS names (which often reflect what's running on the target boxes, and would then include information that could be used as part of an attack vector) to their ISP? I understand how open source works, but most people (including me) don't have the ability to work effectively on this nuanced bug. What's the plan? Sorry to sound disgruntled, but I spent about a week on this (coming to terms with understanding the issue, and then trying a number of workarounds). Initially I accused our CTO of running a broken VPN server (heh), because I could simply not believe that things didn't "just work" in Linux for this extremely common use case. So we don't support pushing "dhcp-option" for DNS in Linux. This works in Mac and in Windows. We need a working/easy way to update our DNS addresses upon connecting to/disconnected from a VPN that users can trust. This bug is so obscene, bwahah, I felt like Linus Torvalds dealing with Nvidia... :-P

[Andy kriger (andy-kriger)]

Please fix this. This is a serious security problem for someone like myself trying to use Linux for work and needing to connect to a VPN on public networks. I have yet to find a workaround that lets me connect to the VPN once I've disconnected from the VPN (for example, moving from one location/public wifi to another, putting my laptop to sleep in between - when I connect to the new wifi network, I cannot connect to VPN).

[Wolfgang Flatter (78luphr0rnk2nuqimstywepozxn9kl19tqh0tx66b5dki1xxsh5mkz9gl21a5rlwfnr8jn6ln0m3jxne2k9x1ohg85w3jabxlrqbgszpjpwcmvkbcvq9spp6z3w5j1m33k06tlsfszeuscyt241hasoyapndax-launchpad-a811i2i3ytqlsztthjth0svbccw8inm65tmkqp9sarr553jq53in4xm1m8wn3o4rlwaer06ogwvqwv9mrqoku2x334n7di44o65qze67n1wneepmidnuwnde1rqcbpgdf70gtqq2x9thj5tlcsac12abiuk2rb)]

Using VPN with Ubuntu in countries with censorshop is not possible. This is a major security issue. How can it be possible, that these bug is still not fixed yet?

[Mr.Gosh (mr-gosh)]

Affects me on Kubuntu 18.10 too!
Trying the 19.04 release now...

[Zack Kollar (seedyrom)]

This is scary thread for a relatively easy fix, for some reason dnsmasq and OpenVPN don't play well together, it's as simple as commenting out the "dns=dnsmasq" line in /etc/NetworkManager/NetworkManager.conf and then restarting network manager.

[Kiruahxh (kiruahxh)]

It affects me too on Ubuntu 19.04 using OpenConnect VPN

[Steve Langasek (vorlon)]

On March 23, 2020 3:08:07 AM PDT, Kiruahxh <email address hidden> wrote:
>*** This bug is a duplicate of bug 1688018 ***
> https://bugs.launchpad.net/bugs/1688018
>
>It affects me too on Ubuntu 19.04 using OpenConnect VPN

Ubuntu 19.04 has reached end of life and is no longer supported. Please upgrade.

[Delany (delany)]

I'm on 19.10 with a L2TP IPsec connection over wifi
using packages: network-manager-l2tp network-manager-l2tp-gnome

I set both the wifi and VPN IPv4 settings to "addresses only"

When I configure the VPN DNS to the remote nameservers, queries go to those nameservers and I can access VPN resources.

But when I ALSO add Cloudflare DNS to my wifi, and switch on VPN, only the Cloudflare DNS is queried. Not event a fallback to the VPN DNS.

[Lukas Dzunko (lukas-d)]

It is impressive how quick there was response and still this and related bug (#1688018) is abandoned for more than 3 years ...

> On March 23, 2020 3:08:07 AM PDT, Kiruahxh <email address hidden> wrote:
> >*** This bug is a duplicate of bug 1688018 ***
> > https://bugs.launchpad.net/bugs/1688018
> >
> >It affects me too on Ubuntu 19.04 using OpenConnect VPN
>
> Ubuntu 19.04 has reached end of life and is no longer supported. Please upgrade.