No dns resolution after closing a vpn/pptp connection

Bug #1778946 reported by Emmanuel DA MOTA on 2018-06-27
110
This bug affects 21 people
Affects Status Importance Assigned to Milestone
ppp (Debian)
New
Unknown
ppp (Ubuntu)
Medium
Unassigned

Bug Description

step to reproduce

set a VPN connection configured to connect a Microsoft vpn server (pptp)

internet acces is ok

enable the vpn connection using the applet on the top right corner of the desktop

internet still ok
ping works

disable the vpn connection

ping doesn't works with a host but works if i specify an ip address

ping: xx.net: Nom ou service inconnu

As a workaround, i disable the ethernet link and re-enable it

name resolution is now ok

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: network-manager 1.10.6-2ubuntu1
ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
Uname: Linux 4.15.0-23-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Wed Jun 27 18:09:30 2018
IfupdownConfig:
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
InstallationDate: Installed on 2014-06-03 (1484 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
IpRoute:
 default via 192.168.0.254 dev eth0 proto dhcp metric 20100
 169.254.0.0/16 dev eth0 scope link metric 1000
 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.47 metric 100
IwConfig:
 lo no wireless extensions.

 eth0 no wireless extensions.
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
RfKill:

SourcePackage: network-manager
UpgradeStatus: Upgraded to bionic on 2018-05-10 (48 days ago)
nmcli-dev:
 DEVICE TYPE STATE DBUS-PATH CONNECTION CON-UUID CON-PATH
 eth0 ethernet connected /org/freedesktop/NetworkManager/Devices/2 Connexion filaire 1 94806bba-1c68-46b6-87f4-a3eeeeaff6dd /org/freedesktop/NetworkManager/ActiveConnection/6
 lo loopback unmanaged /org/freedesktop/NetworkManager/Devices/1 -- -- --
nmcli-nm:
 RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN
 running 1.10.6 connected (site only) started limited enabled enabled enabled enabled enabled

Launchpad Janitor (janitor) wrote :

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

Changed in network-manager (Ubuntu):
status: New → Confirmed
danov (idanov) wrote :

Before start pptp vpn:

$ ls -laF /run/systemd/resolve/stub-resolv.conf
-rw-r--r-- 1 systemd-resolve systemd-resolve 714 jun 30 18:26 /run/systemd/resolve/stub-resolv.conf

After start pptp vpn:

$ ls -laF /run/systemd/resolve/stub-resolv.conf
-rw-r--r-- 1 systemd-resolve systemd-resolve 714 jun 30 18:26 /run/systemd/resolve/stub-resolv.conf

After stop pptp vpn:

$ ls -laF /run/systemd/resolve/stub-resolv.conf
-rw------- 1 root root 714 jun 30 18:26 /run/systemd/resolve/stub-resolv.conf

File /run/systemd/resolve/stub-resolv.conf is readable only for root user.
And DNS is accessible only for root user.

$ ping google.com
ping: google.com: Temporary failure in name resolution
$ sudo ping google.com
PING google.com (172.217.169.110) 56(84) bytes of data.
64 bytes from sof02s31-in-f14.1e100.net (172.217.169.110): icmp_seq=1 ttl=55 time=0.999 ms
..........

seems related to the file /etc/ppp/ip-up.d/0000usepeerdns on line 23-24

cp -a "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"
mv -f "$REALRESOLVCONF.tmp" "$REALRESOLVCONF"

the cp command doesn't preserve file ownership

Will Cooke (willcooke) on 2018-10-24
no longer affects: openvpn-systemd-resolved (Ubuntu)
tags: added: rls-cc-incoming
Sebastien Bacher (seb128) wrote :

It would be a bug in "ppp" which provides that file then and worth reporting to Debian because it's coming from there directly

Will Cooke (willcooke) wrote :

This upstream bug suggests that the problem can be resolved by installing resolvconf:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378363

I will test this, but I'm having problems with VPNs on this network atm.

Will Cooke (willcooke) wrote :

I spoke to stgraber a bit, he said that the resolvconf thing is probably a red herring.

Rasmus Pedersen (sundowndk) wrote :

Installing resolveconf fixed it for me, now DNS resolv works after PPTP disconnects.

Will Cooke (willcooke) wrote :

Also confirming that installing resolvconf makes DNS work once the VPN is disconnected.

cp -a is supposed to preserve ownership. -a means "-dR --preserve=all".

Could someone look at what happens, by displaying more than just the /run/systemd/resolve/stub-resolv.conf file? All files in /run/systemd/resolve/ are relevant here.

This has more smells of being affected my UMASK and probably other settings, otherwise it wouldn't be a perm 600 file.

Nevertheless, running 0000usepeerdns is wrong in all cases, especially with NetworkManager. That file probably should go; replaced by something that will use systemd-resolved's interfaces instead if they are available, and definitely never runs when NetworkManager is running.

Sebastien Bacher (seb128) wrote :

tagging as rls-cc-notfixing, while good to fix it impacts a non default plugin and we don't think it's important enough to be actively tracked by desktop

tags: added: rls-cc-notfixing
removed: rls-cc-incoming
Launchpad Janitor (janitor) wrote :

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

Changed in ppp (Ubuntu):
status: New → Confirmed
Changed in resolvconf (Ubuntu):
status: New → Confirmed
Will Cooke (willcooke) wrote :

Sorry for the delay here.

Is this what you were interested in @cyphermox?

While VPN is up:

$ ls -lha /run/systemd/resolve/
total 16K
drwxr-xr-x 3 systemd-resolve systemd-resolve 140 Nov 28 12:29 .
drwxr-xr-x 20 root root 460 Nov 28 12:28 ..
drwx------ 2 systemd-resolve systemd-resolve 80 Nov 28 12:29 netif
-rw-r--r-- 1 systemd-resolve systemd-resolve 647 Nov 28 12:29 resolv.conf
-rw-r--r-- 1 systemd-resolve systemd-resolve 712 Nov 28 12:29 stub-resolv.conf
-rw------- 1 root root 712 Nov 28 12:27 stub-resolv.conf.pppd-backup.ppp0
-rw-r--r-- 1 root root 728 Nov 28 12:29 stub-resolv.conf.tmp

After VPN is closed:

$ ls -lha /run/systemd/resolve/
total 12K
drwxr-xr-x 3 systemd-resolve systemd-resolve 120 Nov 28 12:32 .
drwxr-xr-x 20 root root 460 Nov 28 12:28 ..
drwx------ 2 systemd-resolve systemd-resolve 60 Nov 28 12:32 netif
-rw-r--r-- 1 systemd-resolve systemd-resolve 647 Nov 28 12:32 resolv.conf
-rw------- 1 root root 712 Nov 28 12:27 stub-resolv.conf
-rw-r--r-- 1 root root 728 Nov 28 12:29 stub-resolv.conf.tmp

Attached are the files after the VPN is shutdown.

Douglas Kosovic (dkosovic) wrote :

I can confirm the issue is the following line in /etc/ppp/ip-up.d/0000usepeerdns as previously mentioned :

cp -a "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

The variable expansion of that line is :
cp -a /run/systemd/resolve/stub-resolv.conf /run/systemd/resolve/stub-resolv.conf.pppd-backup.ppp0

I had to modify the shebang line of that script from :
  #!/bin/sh -e
to :
  #!/bin/sh
to get past that line and output debugging output I inserted, which included :

ls -l /run/systemd/resolve/stub-resolv.conf
-rw-r--r-- 1 systemd-resolve systemd-resolve 720 Jan 17 21:47 /run/systemd/resolve/stub-resolv.conf

ls -l /run/systemd/resolve/stub-resolv.conf.pppd-backup.ppp0
-rw------- 1 root root 720 Jan 17 21:47 /run/systemd/resolve/stub-resolv.conf.pppd-backup.ppp0

So 'cp -a' isn't copying the permissions. Oddly, $? is 0 after running that 'cp -a' line, therefor seems correct, also umask is 0022, so I'm not sure what is going wrong.

Anyway a fix seems to be to change the following line in /etc/ppp/ip-up.d/0000usepeerdns from :

cp -a "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

to:

cp "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"
chmod 644 "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

For Ubuntu 18.04 setups that have the pppconfig package installed, the following lines in /etc/ppp/ip-up.d/0dns-up probably should be changed from :

/bin/cp -Lp "$RESOLVCONF" "$RESOLVBAK" || exit 1
/bin/cp -Lp "$TEMPRESOLV" "$RESOLVCONF" || exit 1
chmod 644 "$RESOLVCONF" || exit 1

to:

/bin/cp -Lp "$RESOLVCONF" "$RESOLVBAK" || exit 1
chmod 644 "$RESOLVBAK" || exit 1
/bin/cp -Lp "$TEMPRESOLV" "$RESOLVCONF" || exit 1
chmod 644 "$RESOLVCONF" || exit 1

Douglas Kosovic (dkosovic) wrote :

Correction the following line in /etc/ppp/ip-up.d/0000usepeerdns probably should be changed from :

cp -a "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

to:

cp -Lp "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"
chmod 644 "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

Douglas Kosovic (dkosovic) wrote :

Sorry ignore comment #16 as the following line in /etc/ppp/ip-up.d/0000usepeerdns will exit because of the '#!/bin/sh -e' shebang line:

cp -Lp "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

So my original suggestion of replacing the following line:

cp -a "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

to:

cp "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"
chmod 644 "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

was correct and won't prematurely exit.

Douglas Kosovic (dkosovic) wrote :

I wasn't able to redirect the stderr from the following line in /etc/ppp/ip-up.d/0000usepeerdns (probably because of something pppd is doing) :

cp -a "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

So I modified the cp.c source from the coreutils package and redirected stderr to a file.

The error message I now see is :

cp: failed to preserve ownership for '/run/systemd/resolve/stub-resolv.conf.pppd-backup.ppp0': Operation not permitted

cp.c is using the lchown() function which is failing with that message.

Looks like only preserving ownership is failing as I tried the following and it works:

cp --preserve=mode,timestamps "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

The way /run is mounted might be the reason why 'cp -a' and lchown() is failing.

Ignore what I said able $? being 0 after the cp -a line. Doing the following line confirms $? is 1 :

cp -a "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE" || echo ERROR $? >> /tmp/usepeerdns-up.log

Douglas Kosovic (dkosovic) wrote :

Comment 6 and 7 in the upstream GNOME NetworkManager-pptp bug report :
    https://bugzilla.gnome.org/show_bug.cgi?id=785771#c6
are relevant to this bug (but not the 'cp -a' issue).

As mentioned, the following exit in /etc/ppp/ip-up.d/000resolvconf when the interface is managed by NM, seems the right solution.

    case "$6" in
      nm-pptp-service-*|nm-l2tp-service-*|/org/freedesktop/NetworkManager/PPP/*)
        # NetworkManager handles it
        exit 0
        ;;
    esac

Perhaps the exit should be added to /etc/ppp/ip-up.d/0000usepeerdns for instances when resolvconf package isn't installed?

Changed in network-manager (Ubuntu):
assignee: nobody → Till Kamppeter (till-kamppeter)
importance: Undecided → Medium
Paul Smith (psmith-gnu) wrote :

Although this problem is easy to fix once you know what to do, I don't know if it should be only "Medium" importance because the impact is massive: no DNS is available. If you're not technically inclined enough to know to go poking around /etc/resolv.conf if DNS breaks, you would never be able to figure out what was wrong with your system and you can't search the internet to find a solution...

As I see the comments here, the fix is to modify the file /etc/ppp/ip-up.d/0000usepeerdns according to comments #17 and #19. /etc/ppp/ip-up.d/0000usepeerdns is part of the ppp package, so the bug needs to be fixed in the ppp package.

Changed in network-manager (Ubuntu):
status: Confirmed → Invalid
Changed in resolvconf (Ubuntu):
status: Confirmed → Invalid

Attached is the debdiff with the proposed fix of comment #19 applied. Someone with appropriate upload rights to Disco, please upload it.

I could not actually test it as I have no access to a Microsoft VPN,

I do not see any regression though. I can access Canonical's VPNs and while having activated one and also after deactivating it I always have DNS correctly working.

To the original poster: As soon as this is in Disco (or building the fixed package by yourself) please test whether this helps. If the fixed package does not solve your problem, we will try the proposed "cp -a ..." fixes.

tags: added: patch
Changed in ppp (Ubuntu):
importance: Undecided → Medium
no longer affects: network-manager (Ubuntu)
no longer affects: resolvconf (Ubuntu)
Changed in ppp (Debian):
status: Unknown → New
Mariano Draghi (chaghi) wrote :

I've manually applied the patch proposed in comment #22 to my Ubuntu 18.10 desktop, and I can confirm that it fixes the issue for me. I haven't seen any regression either, although my testing has been very limited so far.

I've been experiencing this bug ever since Ubuntu 18.04 when disconnecting from my employer's Fortinet SSLVPN (I'm using the network-manager-fortisslvpn package). My previous workaround was to force my wifi up again (even if it was not down) after closing the VPN connection (nmcli c up $my-ssid).

Simon Quigley (tsimonq2) wrote :

Uploaded to Eoan.

If this needs to be SRUed, please adjust the bug description to follow the template: https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template

Thanks!

Changed in ppp (Ubuntu):
status: Confirmed → In Progress
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ppp - 2.4.7-2+4.1ubuntu2

---------------
ppp (2.4.7-2+4.1ubuntu2) eoan; urgency=medium

  * debian/extra/ip-up.d/0000usepeerdns: Added NetworkManager check, which
    lets the script exit when NetworkManager is in use (LP: #1778946).

 -- Till Kamppeter <email address hidden> Fri, 08 Feb 2019 17:37:29 +0100

Changed in ppp (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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