network manager openvpn dns push data not updating system DNS addresses

[Aidan Walton]

[Triage Notes]

This report can no longer make progress. Please see comment 50 for details and further instructions.

[Original Description]

When IPv4 Method is set to Automatic VPN, DNS address recieved from OpenVPN server do not update resolv.conf.

This can be achieved when using a standard openvpn config file by adding the lines:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

In Network-manager there seems to be no option to run connection specific scripts and the DNS data from the server is ignored.

Ubuntu 13.04
Network-manager 0.9.8.0-0ubuntu6

[Launchpad Janitor (janitor)]

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

[ouss (oussjarrouse)]

I am having the same issue on Ubuntu 13.04. But i don't have it on my other machine that is running 12.04 LST

[Paul Edwards (pedwards)]

I'm running 12.04LTS and this effects me. Massively painful that I cannot get DNS servers added from our openvpn server.

[zasran (erik-zasran)]

It seems that the fix suggested in description will not work because /etc/openvpn/update-resolv-conf updates /etc/resolv.conf (it adds the DNS server sent by openvpn server to this file). However /etc/resolv.conf is automatically updated by network manager, second line of this file says:

# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

Not sure what the proper solution is, maybe the entries should be added to some file in /etc/resolvconf/resolv.conf.d/ and /etc/resolv.conf should be regenerated?

[Paul F (boxjunk)]

I have the same problem on Ubuntu 14.04 Trusty Tahr.

Not sure this is a bug, though, just a M$ Windows-only feature as it's a TCP/IP extended property. The man page for OpenVPN describes --dhcp-option as a Windows-specific option.

If the OpenVPN server pushes a DNS server address to the client with, eg

dhcp-option DNS 8.8.8.8

then on a Linux platform this option is not actioned by the client. Instead it is copied to a set of incrementally numbered local environment variables named

foreign_option_{n}

which are available to scripts run by the --up and --down OpenVPN options.

The /etc/openvpn/update-resolve-conf script provided with the OpenVPN package parses these environment variables and
calls resolvconf to effectively do the same job in a Linuxy way.

Comment #5 is invalid since the script uses resolvconf to update /etc/resolv.conf -- it is not edited directly.

This is not, therefore, an OpenVPN bug, excepting that the current OpenVPN solution requires a reduced security policy by allowing builtin executables and scripts to be called when, by design, this is normally prohibited by default.

It is a feature request for Network Manager, though.

[Paul F (boxjunk)]

Feature request?

[Launchpad Janitor (janitor)]

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

[Gabriel Nell (gabriel-nell)]

Would love to see this feature to make a very popular VPN client work seamlessly with Ubuntu. I'm on 14.04 and trying to figure out a work-around for this (probably will disable resolvconf).

[Maykel Moya (mmoyar)]

Works for me after disabling NetworkManager's own dnsmasq. I'm using trusty with the following versions:

* network-manager 0.9.8.8-0ubuntu7pitti1
* network-manager-openvpn 0.9.8.2-1ubuntu4
* network-manager-openvpn-gnome 0.9.8.2-1ubuntu4
* openvpn 2.3.2-7ubuntu3

[Nico (etc)]

I can confirm that this bug does not occur when you disable dnsmasq for NetworkManager.

However, I wanted to add how you can do so:
Open /etc/NetworkManager/NetworkManager.conf in an editor and change
dns=dnsmasq
to this:
#dns=dnsmasq

Then, restart NetworkManager:
sudo service network-manager restart

[Eugene Crosser (crosser)]

I'd like to point out that the description of the bug is inaccurate. When networkmanager uses dnsmasq, resolv.conf should not be updated when new dns servers must be used. Instead, networkmanager needs to update dnsmasq's configuration. And it does not do that, which is a problem.

Proper description should be:
network manager openvpn dns push data not updating system dns addresses

I can confirm that the problem exists on 14.10.

[bitinerant (bitinerant)]

Whether this is a bug or feature request, I don't know, but to be sure, it is possible to do this with a .conf file and "sudo service openvpn start" and not possible to do it via network-manager-openvpn (unless you count disabling dnsmasq--I'm curious what side effects this has). As described in the original report, I have verified that these lines in a .conf file allow the server to configure DNS (as long as the server pushes 3 or more DNS servers):

  script-security 2
  up /etc/openvpn/update-resolv-conf
  down /etc/openvpn/update-resolv-conf

but network-manager-openvpn does not support the 'up' and 'down'.

This same issue was addressed here:

  http://askubuntu.com/questions/519920/how-to-run-an-up-script-using-network-manager-openvpn

[bitinerant (bitinerant)]

Actually, I'd like to retract part of what I said above. Via tcpdump, I was able to confirm that --push on the server for "dhcp-option DNS ..." and "redirect-gateway" ARE ACTUALLY WORKING, though the changes are not visible in /etc/resolv.conf. Rather, they are updated in dnsmasq and resolv.conf points to dnsmasq. (I don't think the "def1" flag for "redirect-gateway" works.)

In my view, two things are needed: (1) a documented way to view the list of DNS servers within Network Manager's dnsmasq so folks here can watch what is happening without tcpdump, and (2) support for "dhcp-option DNS ..." and "redirect-gateway" on the client (not just options pushed from the server). The first item seems more important and should be much easier.

[Björn Lundgren (bjorn-erik-lundgren)]

I can confirm this is still an issue in Ubuntu 14.04 LTS using network-manager-openvpn.

disabling dnsmasq does not fix the issue.

In my opinon this issue is critical since it renders the use of openvpn practically useless through network manager gui.

[JanMalte (janmalte)]

And even in Ubuntu 15.04 the bus still exists. This is a total show stopper for using Ubuntu in a company environment.

[Simon Déziel (sdeziel)]

On 04/29/2015 04:16 PM, JanMalte wrote:
> And even in Ubuntu 15.04 the bus still exists. This is a total show
> stopper for using Ubuntu in a company environment.

While not as user friendly, interacting with OpenVPN's init script works
well in that regard. One only need to enable the update-resolv-conf
helper script:

 script-security 2
 up /etc/openvpn/update-resolv-conf
 down /etc/openvpn/update-resolv-conf

That said, I don't know if the init script is still shipped in Vivid as
OpenVPN now supports systemd.

HTH,
Simon

[Leonidas Spyropoulos (artafinde)]

This is still a bug on 14.04 LTS and the suggested workarounds don't work. Can someone suggests a working workaround?

[Mac (orig-ubuntuone)]

The init script was shipped with my copy of Ubuntu 15.04 and is present in "/etc/openvpn" however the initial bug/problem still remains...

[drm200 (drm200)]

Still a problem with 14.04.02

This work-around works for me .... but I have no idea what the side effects may be:

Open /etc/NetworkManager/NetworkManager.conf in an editor and change
dns=dnsmasq
to this:
#dns=dnsmasq

Then, restart NetworkManager:
sudo service network-manager restart

[Tim K (kelletim)]

Still this is a problem. It is a horrible bug and prevent us from using network manager at all, which is highly inconvenient and nearly breaks the whole system and causes many problems. PLEASE FIX THIS, or tell us how to modify dnsmasq so that it uses the right dns server

[Mac Bassett (mac-bassett)]

I have found a work-around for 14.04 LTS. It's not the prettiest one but it works. When I started a vpn connection and then ran
ps -efwww | grep vpn
I could see that the openvpn is already called with flags "--script-security 2 --up /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper". So the following can be performed.

sudo cp /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper.orig

sudo nano /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper
--- Add the following 3 lines to the file. ---
#!/bin/bash
/etc/openvpn/update-resolv-conf $@
/usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper.orig $@
--- End---

sudo chmod +x /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper

Now here is the really ugly part. Since openvpn was not called with the --down flag, you should run the following command every single time the vpn connection is closed.
Change the device name according to your connection settings.

sudo script_type=down dev=tun0 /etc/openvpn/update-resolv-conf

[Timo Harmonen (timo-harmonen)]

Also problem in 15.10

[Tristan (supersluether)]

Same issue for me on 15.10, but it didn't happen on 15.04.

Using the script-security 2 option in the configuration file, everything works correctly when run from command line: "sudo openvpn --config file.ovpn"

For me, this problem only happens when connecting through Network Manager.

[tjk (tim-klassen)]

I just discovered this issue in a newly upgraded version of Lubuntu 15.10. I tried two of the possible solutions in this thread. The "sudo openvpn --config file.ovpn" doesn't work for me, it gives an error: "Error: Object 'nm' is unknown"... This DNS leak is really annoying because it makes my vpn connection useless!

[Sam (litle-sam)]

This bug is also in Xenial Xerus development.
Sites that use SSO keeps login user out as moving around.
Any dns leak site confirms the leak only on the newer versions of Ubuntu.
This DNS leak is really annoying because it makes my vpn connection useless!

[Andrea Lazzarotto (Lazza) (andrea-lazzarotto)]

A simple workaround is to edit your VPN connection (via NM) and set up static DNS, for example using Google servers:

8.8.8.8, 8.8.4.4

This way, the DNS request is sent through an external IP, hence it is routed using the VPN. If you were using the default DNS from your router (probably an internal IP like 192.168.x.y) then the DNS request would go outside the VPN.

I just discovered that Google provides also IPv6 servers, by searching for "IPv6 DNS Servers" on DuckDuckGo (a very convenient table of DNS servers by provider shows up).

[Tristan (supersluether)]

@Andrea, I tried that, but then my VPN connection uses the static servers. And unless Google DNS connections are encrypted, it's still a DNS leak.

[Andrea Lazzarotto (Lazza) (andrea-lazzarotto)]

Tristan, how is that a leak? Connections to 8.8.8.8 will go through the VPN, not outside of it. By the way, the problem remaining is that sometimes NM seems to still use the DNS of the router as well. It's as if without VPN you have say 192.168.0.1 as primary DNS, but with VPN you get these DNS servers:

8.8.8.8
8.8.4.4
192.168.0.1 (for example)

Then sometimes the third DNS receives the query. I will experiment with setting the static DNS to the Wi-Fi connection as well. Of course it would be easier if this bug actually gets fixed.

[Tristan (supersluether)]

Andrea, a DNS Leak is defined as any DNS traffic going outside your VPN's assigned servers. Even if 8.8.8.8 goes through the VPN, it's still leaking your traffic. https://www.dnsleaktest.com/what-is-a-dns-leak.html

[DaveHenson (davehenson)]

I'm glad to see that I am not the only one fighting this issue on Ubuntu 15.10. This is a real show stopper to this being brought into a production environment. I found the same as post from Tristan on 2015-12-11. I CAN run command line but it is a pain to enter my username/pwd every time I need to launch VPN. There is definitely a bug in how the network manager runs openvpn.

Surprised to see this has been open over 2 years.

[Sam (litle-sam)]

I had some dns leaks in 16.04 as I posted above but it seems the updates over the last few days fixed them. Wished I would have tested for leaks as the updates were coming in.

[Zephyr (munro-w)]

DaveHenson,
It doesn't solve the bug, but I think you can solve the problem of entering your usr/pwd on each connect in terminal by adding your usr/pwd to a simple text file (e.g., file.txt) that is literally nothing but your credentials:

(line 1) usr
(line 2) pwd

located in the same dir. where your .conf or .ovpn file is located. Be sure also to change this credential file's permissions to read/wrt for root only (chmod 600).

Then just change the .conf file itself to include the line
`auth-user-pass file.txt`

Hope this helps.

[DaveHenson (davehenson)]

Thank you Zephyr for the tip. That does help me automate the login somewhat.

As for the fix Sam mentioned, I've been applying every update available for 15.10 and while I thought it was fixed after initial testing, I have found that the DNS is still leaking after subsequent tests. I admit though I have not yet installed 16.04 to verify the fix. Fingers crossed that it really is finally fixed!

[DaveHenson (davehenson)]

just installed 14.04 then upgraded to 16.04 today's daily build. unfortunately still see the DNS leaking issue.

[reliable-robin-22 (nicolasdiogo)]

Really OpenVPN is not a high enough priority for Canonical to have it fixed in over 2 years ?!

I thought Ubuntu was supposed to be a replacement OS for businesses ...

anyhow, it is possible to run the configurations using the command line.

It is a joke to explain to users of other 'OSes' that Ubuntu does not have a GUI that works with OPENVPN.

Apologies for the ranting ... but I do believe it to be necessary.

[reliable-robin-22 (nicolasdiogo)]

about running the OPENVPN via command-line

it is possible to have the option of using a file with the USERNAME & PASSWORD for the OPENVPN stored in a safe location (if you believe that!)

you can add the following into the config:

auth-user-pass {fullpath to file with USERNAME & PASSWORD}

this file should only contain 2 line: the first with the USERNAME & the 2nd with the PASSWORD

Good Luck!

[Nikolas Hedberg (drhedberg)]

I am using Ubuntu 16.04 64-bit and I have tried every option I can find on this thread and on google but nothing seems to work.

The only thing I can do is change my entire systems DNS to the DNS servers of my VPN service for now.

I did find a tutorial on the program dnscrypt which has a PPA that will encrypt your DNS. I'm going to give that a try.

Thanks to whoever comes up with a solution.

[Magnus Olsen (mucilago-8)]

Running the following command from Terminal solved to problem for me. Only hassle is that I have to log in every time with my pass and username (for vpn): sudo openvpn --config file.ovpn

Be sure to find the correct folder where the relevant ovpn file is via terminal, and then execute the before mentioned command.

[Asylum (asylum119)]

Signed up just to show my frustration with this particular bug and am currently upgrading to 16.04 with fingers crossed that Sam was correct and this has been rectified.

[sveng (sveng)]

https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1211110/comments/20

solved the problem for me on ubuntu 16.04.
Btw, I only ran into this problem in ubuntu , in kubuntu 14.04 it was no problem. Tthe settings in
kubuntu 14.04: /etc/NetworkManager/NetworkManager.conf are
#dns=dnsmas

as drm200 #20 suggested.

[Henry Yei (henry-yei)]

The issue appeared on UBuntu 16.04 LTS, and getting rid of dnsmasq in Network Manager solved the issue for me as well.

[Asylum (asylum119)]

To stop my OpenVPN DNS leak I ended up doing the following

Disabled dnsmasq as described above
Installed unbound so /etc/resolv.conf was not using my routers DNS intermittently when connected to the VPN
Added my VPN's DNS IP's as well as adding the line block-outside-dns to /etc/resolv.conf
Using this as a killswitch https://www.privateinternetaccess.com/forum/index.php?p=/discussion/1151/pia-iptables-manager#Item_4

[Christophe H (chrissc-humbert)]

Hello

Same issue here on KDE 16.04 and the DNS mask trick does not seem too resolve the issue

Kind Regards

[Chadd Hudson (chadd-hudson)]

Just did a fresh install of 16.04, added network-manager-openvpn,
network-manager-openvpn-gnome,
network-manager-pptp,
network-manager-vpnc

then I was able to import my vpn configuration files via an import script from my vpn provider, reboot (since "service networking restart" no longer works), and connected to my vpn. confirmation through https://ipleak.net/ and https://www.dnsleaktest.com/ shows no other DNS than my provider.

This bug appears to be resolved. (to me.)

[5a54a (5a54a)]

Please ignore my answer above. It does solve my problem with the OpenVPN connection, however is does not seem to solve isseu regarding the updating of the DNS problem completely. I seems like the DNS from the OpenVPN server is being used, but also other DNS ip's (from my router) are still being used.

[kuntergunt (kuntergunt)]

I had openvpn configured and it used to work. Now, after quite a while not using it, openvpn still connetcs but the DNS push is not working any more. Some update must have broken this. I am on 16.04.

[domnulnopcea (domnulnopcea)]

is this bug going to be addressed somehow....?

[Mathieu Trudel-Lapierre (cyphermox)]

I've maintained NetworkManager for a while, and routinely use OpenVPN for various things. Pushing nameservers from the openvpn server to the client works as intended, as far as I can tell. If you use the default settings, which I believe are to tunnel everything through the VPN, you will only use the nameservers pushed by your VPN, and if using split tunnelling, you will use any nameservers already defined for you "local" connection, PLUS VPN nameservers.

All this is handled by dnsmasq, and largely depends on what information it is fed. In the case where there are no search domains passed by the VPN server, all we can do is add the nameserver from the VPN as an IP address. In this case, if split tunnelling is enabled, DNS requests may happen on any of the nameservers defined, regardless of whether they come from the ISP, from the VPN, or elsewhere.

If no split-tunnelling is being done; then the VPN nameserver(s) REPLACES the nameserver otherwise set in dnsmasq. Along with the fact that all the traffic is routed through the VPN, this means all the network traffic will happen over the VPN, including DNS requests.

You can check in NM, under the connection's IPv4 and IPv6 tabs, behind the "Routes.." button, if "Use this connection only for the resources on its network" checkbox is checked. If you want all traffic to go through the VPN, it *MUST NOT* be checked. If you want to use split tunnelling, then it can, but you should configure your VPN to pass search domains along with the nameservers to ensure they are only used on the right domains.

Things have been working this way at least for a few releases, probably since Trusty (14.04). Bugs happen here and there of course, but we've been fixing them as they popped up. The important thing here is that they need to be well defined, explained so that we really understand what is the issue you're facing, what kind of VPN you use, and how your system (and more importantly your VPN connection) is configured.

Setting up VPNs correctly typically requires a fair amount of understanding of how networks work in general, along with the extra knowledge of what VPNs do exactly. If you're not the person who configured the VPN servers, it's *much* better to ask them to file a bug here to explain the issue in as much detail as possible, and including any non-security-sensitive details about the VPN setup as they can.

Additionally, we've done a "minor" fix in 16.10 (the development release) to avoid leaking search domains (see https://launchpad.net/ubuntu/+source/network-manager/1.2.2-0ubuntu4). If you feel like you've been seeing this, you may want to try out Ubuntu using a live CD to see if the fix provided helps with your particular setup.

Finally; from the looks of things and from my experience with these kinds of bugs, there are far too many comments on this bug for everyone to be having the exact same issue, considering things appear to largely work correctly to me. What this means is that many of the commenters here are actually seeing quite different issues; maybe related to VPN, maybe not -- any bugs can be fixed, but they need to be isolated correctly...

In other words, if you think you are seeing...

[domnulnopcea (domnulnopcea)]

Hi,

you said

You can check in NM, under the connection's IPv4 and IPv6 tabs, behind the "Routes.." button, if "Use this connection only for the resources on its network" checkbox is checked. If you want all traffic to go through the VPN, it *MUST NOT* be checked. If you want to use split tunnelling, then it can, but you should configure your VPN to pass search domains along with the nameservers to ensure they are only used on the right domains.

I use split tunneling but I did not configure VPN to pass search domains along with the nameservers. Can't this be done automatically? For example the same vpn configuration works flawlessly in debian jessie. There I do not have to configure search domains and nameservers...

thanks

[Robie Basak (racb)]

Mathieu linked:

"""
* debian/patches/dns-manager-don-t-merge-split-DNS-search-domains.patch: do
    not add split DNS search domains to resolv.conf; doing so would risk
    leaking names to non-VPN DNS nameservers when attempting to resolve non-
    FQDN names. (LP: #1592721)
"""

You ask:

> I use split tunneling but I did not configure VPN to pass search domains along with the nameservers. Can't this be done automatically?

The answer to me appears to be "no", because then you risk leaking names to non-VPN DNS nameservers.

[Tomodachi (tomodachi)]

I can confirm that this is a bug on Ubuntu 16.04.

I'm also responsible for the VPN server in our company so I can do all the necessary debugging if want something verified.

We push 2 DNS servers along with the proper search domain to all clients.
this works for other operating systems like Fedora (also using network manager) and OSX
so for me its clearly a bug client side in Ubuntu.

The bug is evident both on 16.04 and 14.04

we do NOT route all traffic through the VPN tunnel only VPN traffic. Which is a common use case when you don't want to do the heavy lifting of unrelated traffic for hundreds of simultaneous users.

[Frank Scholten (g-frank-f)]

I am new to the Ubuntu community and the intricacies of openvpn, networkmanager etc but I can confirm this bug on Ubuntu 16.04. I can also confirm the following workarond.

When I disable dnsmasq in NetworkManager, add script-security 2 and up & down stanzas for /etc/openvpn/update-resolv-conf the DNS servers are added to /etc/resolv.conf. But when I stop the foreground openvpn process with ctrl-c the previous pushed DNS servers /etc/resolv.conf are not removed.

Ideally /etc/resolv.conf would be restored to the way it was before the openvpn connection.

I would like to help out with this but I don't know which system (openvpn, resolvconf, dnsmasq, networkmanager) would or should be responsible for this.

[Marco (marcoalexandrerico)]

Hi,

I also thought I had a bug on this, but actually the problem is configuration of search domains for VPN resolutions.
I have an updated Ubuntu 16.04 and the scenario described here works for me.

Network Manager uses dnsmasq for DNS resolution so the /etc/resolv.conf name server is always 127.0.1.1 independently of the VPN being up or down. Don't expect /etc/resolv.conf to change nameserver values.
The only thing that is updated in resolv.conf are the search domains.
Having 127.0.1.1 in resolv.conf points the DNS resolutions to the dnsmasq daemon which is running locally.

In the scenario that you have an ethernet connection and a VPN connection, you need first to decide if you want your traffic all to go through the VPN connection or not. This is done by the configuration "Use this connection only for the resources on its network" inside IPV4 Settings->routes (it can also be forced by the VPN Server, just check where is pointing the first 0.0.0.0 route in netstat -r).
In my case VPN server is not forcing and I want traffic to go through both interfaces (split tunnel) so the option is checked.

With the VPN up you'll have DNS servers for the ethernet connection and the DNS servers for the VPN connection. They can be automatically given by DHCP or statically assigned by you. You can even add additional DNS servers to the ones you receive automatically.
Having DNSs in both sides you need to use search domains to decide if you are going to use DNS from one side or the other.
Similar to the DNS servers you can also receive those search domains by DHCP for each interface and you can also add your own.

The problem I had with resolution was that I was trying to resolve VPN domains which where not being pushed as a search domain by the VPN and so they were being sent to the ethernet DNSs instead of the VPN DNSs.
Basically to solve this I had to add the VPN search domains manually in IPV4 Settings.
(easier than ask VPN server admins to push the correct search domains when the VPN comes up)

Hope this helps.

[Marco (marcoalexandrerico)]

Hi,

An update to my previous post.
There is still a bug in 16.04 about this:

- If you add the search domains yourself in IPV4 Settings everythings works
- If you receive search domains from the OpenVPN server, dnsmasq seems not to take them into consideration and names are not resolved. The workaround for this is to add manually on the VPN connection IPV4 settings the search domains that are being pushed by the OpenVPN server.

[Dmitry (strangeadvisor)]

Hi all. It really problem now on 16.04.

But i found funny fix for it. It is not very pretty, but i think it is helps someone.

First step:
Add
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

in your .ovpn client file.

Second step:
Ubuntu can't have more that 3 dns records in /etc/resolv.conf
So, add 3 dns records in server.conf using push-dns
push "dhcp-option DNS firstdns"
push "dhcp-option DNS seconddns"
push "dhcp-option DNS thirddns"

where firstdns,seconddns,thirddns put your dns servers.

It is resolved problem for me without disable dnsmasq or other manipulations.
I hope, i help to someone.
I will waiting a normal resolve this problem with all.

[Micah Mangione (randomlogic314)]

I had the problem with Ubuntu 16.04 out-of-the-box. After a full week of 12 hour days trying to resolve this issue, I was finally about to fix it. I made a longer post about it here.

http://askubuntu.com/questions/829204/dns-routing-fails-for-vpn-connections-on-ubuntu-16-04-out-of-the-box

Here's the abbreviated version.

Step 1: Goto GitHub and clone the following repo to your home folder:
https://github.com/masterkorp/openvpn-update-resolv-conf

Step 2: Move the .sh files from your cloned rep to the /etc/openvpn folder:
sudo chmod +x *.sh && sudo mv *.sh /etc/openvpn

Step 3: Run the following command to install new packages for DNS:
sudo apt-get install openresolv nscd unbound

Step 4: Append the following line to your OpenVPN Client Configuration files (*.ovpn or *.conf). I did this after the configuration directives but before my inline certs (<ca> tag):

script-security 2
up "/etc/openvpn/update-resolv-conf.sh /etc/openvpn/update-systemd-network.sh"
down "/etc/openvpn/update-resolv-conf.sh /etc/openvpn/update-systemd-network.sh"

This should resolve the DNS resolution problem.

Dmitry has the right steps, but I needed the 2nd script for my system to update.

Works like my 14.04 system... before I upgraded to 16.04...

[kuntergunt (kuntergunt)]

I have the same problem. After establishing the connection I can ping all IP's, even the DNS server in the VPN network. But DNS resolve for servers in the VPN network does not work. I have even set the DNS servers IP and the domains to resolve in the network managers VPN configuration (in IPv4 settings) and set it to addresses only. It is still not resolving any VPN network addresses. Global addresses are resolved.

That was working in older versions of Ubuntu. I cannot tell when this was broken because I do not regularily use VPN, but the configuration was there and working in some previous release. I have upgraded this machine now for quite some years. Now in 16.04 it is broken. On a Windows machine that I tested it is still working.

[Vincent Gerris (vgerris)]

@https://launchpad.net/~cyphermox Mathieu, why are you marking this as Incomplete?
Can you be specific in what kind of information you need to consider it complete, instead of pointing people to a DNS admin, who may not be interested in filing a bug?

Some people clearly described how the behaviour changed from 14.04 and I can confirm this.
The current setup is nowhere near a working solution that a normal user that gets VPN connection info can work with.
That hurts business users and pisses developers and users off that even want to make an attempt to make it work.

The net is flooded with issues regarding VPN and DNS, it would be great if you can point us to the right steps and information to supply to actually get this working like say the cisco AnyConnect secure mobility client.
With the exact same VPN server, I can use that tool on Mac OS X without ANY configuration and it "Just works".

I would say the goal is to have it working like that for everybody using network manager.
Let's talk defaults, settings and requirements and I'll try to get the server info or anything else that is needed.

[Andrea Lazzarotto (Lazza) (andrea-lazzarotto)]

Indeed! And on Yakkety the situation is even worse. With the new VPN menu the first VPN connection leaks DNS, the following connections do not work until one changes the resolv.conf file to some static IP.

Compare this to running openvpn from the terminal (which works perfectly) and you will see the problem is huge.

[George Velimachitis (gvelim)]

I managed to get OpenVPN working from within Network-Manager using the following setup

1. Setup your OpenVPN connection in Network Manager using "Network Connections / Add / OpenVPN"
2. Create a new LAN/WLAN connection e.g. "LAN VPN"
3. In "General" Tab set "automatically connect to VPN" and select the OpenVPN entry
4. In "IPv4" tab set "DHCP Address only" and set DNS address of the VPN provider manually
5. Save and test

You should be able to select "LAN VPN" connection which will kick-off the OpenVPN which will then make use of the DNS entry that is manually provided.

So you indirectly activate the VPN connection which also gives you no DNS leaks.

PS: In /etc/NetworkManager/NetworkManager.conf I had to comment out the dns=dnsmasq entry.

[Mark Kirkwood (mark-kirkwood)]

I'm seeing this with 16.10 i.e no vpn nameservers or domains added to resolv.conf when the vpn activated. Doing as suggested in prev(#62) and commenting out 'dns=dnsmasq entry' gets the nameservers appearing in resolv.conf, but *not* the extra domains. So progress, but not there yet!

[goran (gsustek)]

Comment to: Marco (marcoalexandrerico) wrote on 2016-09-02:

Hi, i understand you setup with search domains and split/tunnel, and it works, but what if you are inside intranet and you go through proxy to establish vpn tunnel and go to internet through your router at home. the problem is that your internet DNS are used when you try to search intranet DOMAIN, but what about internet, which search domain would enter?

To all, regarding vpn tunnel after upgrading to 16.10, yes it is even worse, the first VPN connection works as it should, but after disconnect/connect, DNS from VPN isn't propagated...

And something odd about routing... after i create VPN connection i can do some host route, and it works on 16.10 and 16.04(the whole traffic is router through VPN but not host routes which i enter manualy) but if i try to add some network route on 16.10 the traffic then is not routed through VPN anymore....on 16.04 is fine... some thoughts?

[felix archambault (archf)]

I have this issue on ubuntu 16.04.

My current workaround to stop the leak is to add entries such as.

```
cat /etc/NetworkManager/dnsmasq.d/hosts.conf
server=/mydomain/dnsip
```

Hopefully dns don't change much. Filename is not important. It's gonna be pickup by the NM and dnsmasq.

I don't know what part of the big thing it is no trigging the update...

[goran (gsustek)]

it seems that dnsmasq is creating this problem. Is it possible to setup dnsmasq resolving multiple DNS for IP?

[goran (gsustek)]

Folks i resolv my issue of splitting VPN and DNs leaking with hosts.conf and parameters:

strict-order
server=/sub.dom/10.100.11.116
server=/dom/10.100.11.66
server=//10.100.22.11
server=/100.10.in-addr.arpa/ #

it seems that NM works quite fine;-)

[WalterNicholls (walter-nic)]

This might be my a-ha moment from comment # 64 "after upgrading to 16.10, yes it is even worse, the first VPN connection works as it should, but after disconnect/connect, DNS from VPN isn't propagated"

I came to this bug because suddenly my VPN connection wasn't working when I *swear* it was yesterday. I didn't have (/don't remember having!) any problems under 16.04, obviously the 16.10 update was recent. I'm about to reboot - if it comes right after that, then I'll be able to confirm this diagnosis. That said, interesting discussion on http://askubuntu.com/questions/838948/16-10-fail-to-resolve-dns - is dnsmasq out of the equation now? That would suggest problems with upgrading from 16.04 to 16.10 not reconfiguring (and maybe the commenting-out of dns=dnsmasq is the missing sort of step).

Also agree with Mathieu in comment # 50 that this bug report is way past its use-by date. It was started for 13.04 and now we're discussing the 16.04 to 16.10 upgrade? Similar symptoms, but highly unlikely that the same remedy would work across all these versions.

[WalterNicholls (walter-nic)]

On 16.10 - Confirmed that after reboot, my VPN-pushed DNS comes back, on second connection it is missing. I've logged a fresh Bug #1644098 pertaining ONLY to this issue. (Please don't pollute it with "DNS doesn't work at all" comments!)

[Uldis Kalniņš (ulcha)]

Probably duplicate of https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1390623

[Vincent Gerris (vgerris)]

Since this number comes before the other, if it were a duplicate, it would be the other way around.
While maybe related it is another bug related to ipv6 as far as I can read.

The pile of crap coming from changes in networkmanager, vpn, dnsmasq or wherever they come from is horrible : I have never had so many things breaking over a release and never so vital.

While I am not happy with the content and tend to disagree, please follow the suggestion of post 50. Let's try to be as specific as possible and file the bugs like that. Thank you

[Launchpad Janitor (janitor)]

[Expired for openvpn (Ubuntu) because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for network-manager (Ubuntu) because there has been no activity for 60 days.]

[Hugo (hugo-deprez)]

Hello,

I have the same issue on ubuntu 16.10 yakkety

[Rolf Kutz (vzsze)]

This issue still exists in Xenial for me.

[Jose Valencia (jvalenciag4)]

Same issue on ubuntu 16.10 yakkety too.

[Michael Sclectera (msclectera)]

I suggest following the workaround in comment #58 by Micah Mangione (ok123jump-z).

$ git clone https://github.com/masterkorp/openvpn-update-resolv-conf
$ sudo chmod +x ~\openvpn-update-resolv-conf\*.sh && sudo mv *.sh /etc/openvpn
$ sudo apt-get install openresolv nscd unbound

Then add these lines to \etc\openvpn\*.ovpn:

script-security 2
up "/etc/openvpn/update-resolv-conf.sh /etc/openvpn/update-systemd-network.sh"
down "/etc/openvpn/update-resolv-conf.sh /etc/openvpn/update-systemd-network.sh"

This worked perfectly in my case (Ubuntu 16.04.1 LTS Xenial + OpenVPN 2.3.10).

[Andrea Lazzarotto (Lazza) (andrea-lazzarotto)]

@msclectera, the problem is not in OpenVPN config files. The problem is in NetworkManager (that does not store configs in .ovpn format and does not support running update-resolv-conf.sh).

Most (if not all) of us are already using OpenVPN configs that include up and down scripts, nevertheless these settings get lost when imported into NM. Of course openvpn from terminal works, but that is not really the point of this bug.

[Yevheniy (gekapes)]

It is still present in Kubuntu 17.04

[Nico R (u-nico-c)]

Can confirm: Still present in Kubuntu 17.04.

Excerpt from /var/log/syslog:

May 9 10:52:20 edbook NetworkManager[938]: <info> [1494319940.4289] vpn-connection[0x561ae8e38690,34bc52ee-321f-42eb-af39-9dfc33ee2c5c,"WorkVPN",7:(tun0)]: Data: Internal DNS: 10.42.10.2
May 9 10:52:20 edbook NetworkManager[938]: <info> [1494319940.4289] vpn-connection[0x561ae8e38690,34bc52ee-321f-42eb-af39-9dfc33ee2c5c,"WorkVPN",7:(tun0)]: Data: DNS Domain: '[localdomain_propagated_by_vpn]'

----

ico@edbook:~$ nmcli device show tun0
GENERAL.DEVICE: tun0
GENERAL.TYPE: tun
GENERAL.HWADDR:
GENERAL.MTU: 1500
GENERAL.STATE: 100 (connected)
GENERAL.CONNECTION: tun0
GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/10
IP4.ADDRESS[1]: 10.52.0.2/24
IP4.GATEWAY:
IP4.ROUTE[1]: dst = 10.42.0.0/18, nh = 10.52.0.1, mt = 50
IP4.ROUTE[2]: dst = 10.42.90.0/24, nh = 10.52.0.1, mt = 50
IP4.ROUTE[3]: dst = 10.42.80.0/24, nh = 10.52.0.1, mt = 50
IP6.ADDRESS[1]: fe80::e9e3:17e7:f72:e672/64
IP6.GATEWAY:

Also, since dnsmasq appears not to be used anymore in favor of systemd-resolved, the "old" workaround of commenting out the
dns=dnsmasq
line in NetworkManager.conf isn't applicable anymore.

[Çağatay Yüksel (alicagatayyuksel)]

On Ubuntu 17.04, I could get this working with the following steps:

1. rm -rf /etc/resolv.conf

This will tell systemd-resolved not to manage resolve.conf file. Simply disabling systemd-resolved service does not work because of some other depending service is enabled and starts systemd-resolved anyway.

2. Add this line to the [main] section of /etc/NetworkManager/NetworkManager.conf
dns=dnsmasq

Appeartently network manager manages its own instance of dnsmasq so if you have dnsmasq package installed, you should make sure the dnsmasq service is not enabled otherwise this will not work. You can also install dnsmasq-base package instead, which does not include a systemd unit.

A reboot probably is also necessary, I did these via ansible playbooks to create bootable images so this was the case for me. Restarting network manager service might also work.

Hope this helps, best

[CrazySky (makarovdenis11)]

Ubuntu 16.04.

Problem exists

[Silas Brändlin (s-braendlin)]

wow, this was opened in 2013...linux users are really patient! I will restart my Ubuntu Mate and boot into Win10...where I can use openvpn config files...pushed dns server...log verbosity...

Pls don't get me wrong...I love linux...but bugs like this one gets me nuts...2013...wow...even I know to use the command line quite well...this is not user friendly at all...

peace out!

[bagl0312 (bagl0312)]

Actually it was solved on 17.04 :)

https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624317/comments/82

Enjoy!

[Vincent Gerris (vgerris)]

@Silas
Linux users are patient indeed and they are certainly not waiting for useless comments like yours.
If you want to contribute, educate yourself and try to help out. Ranting does contribute NOTHING.
So if you really love Linux, think about that.
Try to follow the rules regarding the bug report and contribute where you can and people will like it.

Nobody asked you to use Ubuntu, if you're happy with windows 10 (which probably nobody else here is) then use it and be happy, why post here?
Don't forget Linux is a community effort and the ways to fix certain problems is difficult.
However, making an effort to get it to work will teach you and will get you appreciation from others.

As bagl0312 commented already, your point is not even viable, because the issue was fixed in 17.04 by a patch.
If you google the issue for older versions, you will probably land on a page that describes how to fix that too:
https://askubuntu.com/questions/838948/16-10-fail-to-resolve-dns
 and see work arounds in this thread, so your comment is really just bad timing.

Please think twice before you post something and read the rules.
Thanks to the relentless efforts of the community, this is fixed and work is going on to get this in the main version(s).

[mc (matic-cankar)]

It still exists in 16.04.

[Andrea Lazzarotto (Lazza) (andrea-lazzarotto)]

As said above, it is fixed in 17.04 so you just have to upgrade.

[mc (matic-cankar)]

@andrea-lazzarotto thank you for your information. I saw, that it is fixed in 17.04, but I would like to stay on long-term-support version and I still hope that it will be fixed for 16.04 too. I understand that it cannot be fixed for all possible versions, but IMHO LTS version should have this privilege.

[gatopeich (gatoguan-os)]

This issue has been bothering more of a hundred users for more than a year. In my case there was a workaround at some point, by downgrading openvpn to an older version (can't remember which).

Being so prevailing and old, it is quite disgraceful that this is not being addressed on Ubuntu 16 LTS.

Instead, I see some wall of text here (e.g. comment 80) trying to excuse the inexcusable.

[Joe Liau (joe)]

This is still an issue in Ubuntu 17.10

Though it seems to fix if you restart NetworkManager first before connecting to the VPN.

sudo service NetworkManager restart

[bagl0312 (bagl0312)]

I confirm that the DNS leakage problem is still present in ubuntu 17.10

[Hashem Nasarat (hnasarat)]

Here's how you fix the issue:

This is a bug that's fixed in upstream NetworkManager. That said, the various GUI tools which write the NetworkManager config files haven't been updated to ensure that DNS leaks are prevented when using vpn connections.

To prevent system dns from appearing and being used in /etc/resolv.conf when using a VPN, edit your vpn configuration (i.e. the file in /etc/NetworkManager/system-connections/<vpn name>) so it's something like this:

[ipv4]
dns=<vpn dns server ip address>;
ignore-auto-dns=true
method=auto
dns-priority=-1

the negative dns-priority means only this dns server will be used.
Then reload the config file:
sudo nmcli c reload <vpn name>

and toggle the vpn.

/etc/resolv.conf should now only include the one dns ip address defined in the config file.

References:
https://developer.gnome.org/NetworkManager/stable/settings-ipv4.html
https://bugzilla.gnome.org/show_bug.cgi?id=758772

[Jens Finkhäuser (finkhaeuser-consulting)]

I can confirm the workaround in #92 for my 16.04.3 LTS installation.

[enr (nylonstrap)]

I have also just encountered this problem on 18.04 development branch.

[kororos (lkororos)]

I am having the same problem with Ubuntu 18.04 LTS release

[FrancisJiang (287459525-7)]

Having the same problem with Ubuntu 18.04 LTS release.

[Antti Raila (anttir)]

@hnasarat, can I set up two DNS servers this way?

[Jean (alessandro-lai85)]

I had this same issue and I circumvented it installing the update-systemd-resolved script through the openvpn-systemd-resolved package.

Yesterday I installed the updates on my Ubuntu 18.04 and it broke. I reported it to the other package, but it seems the root cause is in NM: https://github.com/jonathanio/update-systemd-resolved/issues/64#issuecomment-494128506

> update-systemd-resolved is not getting called on the up command at all, however, /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper is. This seems to be taking over control. Looking at #20 on the OpenVPN tracker, it doesn't support multiple up commands. It also fails silently and there seems to be no interest in fixing it...

> You should see these under DNS Servers and one of them selected for Current DNS Server when you look at the systemd-resolve --status for tun0. If not, then this should be considered an upstream bug for NetworkManager, as the helper is not sending the correct settings through the DBus connection to NetworkManager (or NetworkManager is not acting on it properly if it is).

[Sebastien Bacher (seb128)]

@alessandro-lai85, could you open a new report? If that problem just started then it might be a side effect of the recent network-manager SRU update. Could you also try downgrading to the previous version (https://launchpad.net/~ubuntu-security/+archive/ubuntu/ppa/+build/15599058) to see if that resolves the issue?

[Jean (alessandro-lai85)]

I can confirm that downgrading fixes the issue. I'll open a new report.

[Jean (alessandro-lai85)]

Done: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1829838

[Robie Basak (racb)]

@gatopeich

Please don't load the bug description with personal opinions. Comment 50 is from an Ubuntu developer expert in the area, explains why this particular "report" cannot make progress, provides a path forward for users affected by these symptoms and so is the most relevant for users first finding this bug to read. Let's not put them off by wording that makes it seem like nothing can be done.

[Launchpad Janitor (janitor)]

[Expired for openvpn (Ubuntu) because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for network-manager (Ubuntu) because there has been no activity for 60 days.]