I spoke too soon - the issue seems to have returned under v76.
Ubuntu 17.10
PIA client v76 beta (9b8d0c5)
When PIA is connected and everything is working:
> readlink /etc/resolv.conf
> cat /etc/resolv.conf
nameserver 209.222.18.222
nameserver 209.222.18.218
> cat /run/resolvconf/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
> readlink /tmp/pia_resolv_conf_data
> cat /tmp/pia_resolv_conf_data
# Generated by NetworkManager
nameserver 127.0.1.1
When the PIA client is open, but disconnected, I can't reach any remote hosts:
> readlink /etc/resolv.conf
> cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 127.0.1.1
> cat /run/resolvconf/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
> readlink /tmp/pia_resolv_conf_data
> cat /tmp/pia_resolv_conf_data
# Generated by NetworkManager
nameserver 127.0.1.1
And when PIA client is closed, same results as when it's open but disconnected.
Once again, recreating the resolv.conf symlink like this has (at least for now) fixed the issue.
@islemaster I see that you're on Ubuntu 17.10, which should be using systemd-resolved. Can you check if systemd is running with "sudo systemctl status systemd-resolved.service", and if it is enabled/running can you run these commands and reboot?
I thought resolvconf handling would make it into v77 but it got moved to v78 to avoid delaying v76/v77 even more. On the systems we've tried (16.04 and 17.10 because 17.04 is not installable anymore), it worked in the default configuration (16.04 doesn't put 127.0.1.1 in resolv.conf out of nowhere, it just leaves it as-is which doesn't break anything).
@Max-P That seems to be working better! I guess I was recreating the symlink incorrectly.
Checking systemd's status showed it was active.
I now see the following:
> readlink /etc/resolv.conf
/run/systemd/resolve/stub-resolv.conf
> cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
...with the same results whether PIA is connected, disconnected, or closed, and my connection is working in all three configurations. This behavior has persisted across multiple reboots.
Thanks for all your help and your patience as I keep coming back with the same issue!
@islemaster Yep! That's how it's supposed to work on 17.04 and 17.10!
Basically those versions moved to configured DNS via systemd-resolved, which also acts as a cache. This way, instead of maintaining and overwriting the DNS file, NetworkManager talks directly to systemd-networkd to update the DNS configuration. That way it's bound directly to the network interface that provides said DNS server and automatically select the correct one(s). This also means we don't override the entire DNS either, so in theory local name lookup should also work provided it is configured properly to do so.
v76+ takes advantage of this and also configures DNS in systemd-resolved, so as soon as the tun disappears it takes care of cleaning up and everything for us. It's much, much cleaner and also a lot more reliable.
You can check the DNS status with the following command:
@Max-P Ever since installing the PIA app my DNS breaks every time I reboot and I'm getting really tired of manually inserting a nameserver in /etc/resolv.conf to get my internet working again. I'm currently on v80 and Ubuntu 18.04 but I also had the same problem before upgrading from 16.04. This problem persists even if I don't start the PIA app at boot.
My current resolv.conf points to ../run/resolvconf/resolv.conf with only 127.0.0.1 listed as a nameserver and redirecting it to /run/systemd/resolve/stub-resolv.conf doesn't fix anything.
Comments
When PIA is connected and everything is working:
> readlink /etc/resolv.conf > cat /etc/resolv.conf nameserver 209.222.18.222 nameserver 209.222.18.218 > cat /run/resolvconf/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # 127.0.0.53 is the systemd-resolved stub resolver. # run "systemd-resolve --status" to see details about the actual nameservers. nameserver 127.0.0.53 > readlink /tmp/pia_resolv_conf_data > cat /tmp/pia_resolv_conf_data # Generated by NetworkManager nameserver 127.0.1.1> readlink /etc/resolv.conf > cat /etc/resolv.conf # Generated by NetworkManager nameserver 127.0.1.1 > cat /run/resolvconf/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # 127.0.0.53 is the systemd-resolved stub resolver. # run "systemd-resolve --status" to see details about the actual nameservers. nameserver 127.0.0.53 > readlink /tmp/pia_resolv_conf_data > cat /tmp/pia_resolv_conf_data # Generated by NetworkManager nameserver 127.0.1.1And when PIA client is closed, same results as when it's open but disconnected.Once again, recreating the resolv.conf symlink like this has (at least for now) fixed the issue.
I thought resolvconf handling would make it into v77 but it got moved to v78 to avoid delaying v76/v77 even more. On the systems we've tried (16.04 and 17.10 because 17.04 is not installable anymore), it worked in the default configuration (16.04 doesn't put 127.0.1.1 in resolv.conf out of nowhere, it just leaves it as-is which doesn't break anything).
Checking systemd's status showed it was active.
I now see the following:
> readlink /etc/resolv.conf /run/systemd/resolve/stub-resolv.conf > cat /etc/resolv.conf # This file is managed by man:systemd-resolved(8). Do not edit. # # 127.0.0.53 is the systemd-resolved stub resolver. # run "systemd-resolve --status" to see details about the actual nameservers. nameserver 127.0.0.53Thanks for all your help and your patience as I keep coming back with the same issue!
Basically those versions moved to configured DNS via systemd-resolved, which also acts as a cache. This way, instead of maintaining and overwriting the DNS file, NetworkManager talks directly to systemd-networkd to update the DNS configuration. That way it's bound directly to the network interface that provides said DNS server and automatically select the correct one(s). This also means we don't override the entire DNS either, so in theory local name lookup should also work provided it is configured properly to do so.
v76+ takes advantage of this and also configures DNS in systemd-resolved, so as soon as the tun disappears it takes care of cleaning up and everything for us. It's much, much cleaner and also a lot more reliable.
You can check the DNS status with the following command:
My current resolv.conf points to ../run/resolvconf/resolv.conf with only 127.0.0.1 listed as a nameserver and redirecting it to /run/systemd/resolve/stub-resolv.conf doesn't fix anything.