Sunday 15 September 2019

Ubuntu 18.04 no DNS after VPN

Symptoms

On Ubuntu 18.04, once you connect to VPN (OpenVPN, L2TP or other point-to-point protocols), your system will use the remote peer's DNS server, unless explicitly configured not to use peer DNS. Once the VPN session is closed, local name resolution does not work.

Root cause and quickfix

Turning off and then back on the physical network interface (WiFi or wired) fixed the issue. On this version of Ubuntu, systemd-resolve is responsible for managing changes to, and configuration of domain name resolution. Running systemd-resolve --status correctly shows the original nameserver that was assigned when the connection via the physical interface was established, however this nameserver is not marked as the default and in fact there is no default nameserver once the VPN session is closed.

A quick command like the following recovers the issue: systemd-resolve --set-dns=192.168.0.1 --interface=wlp4s0 but does not resolve the root cause. Further analysis has shown that the error is caused by a file permission issue due to lacking integration of systemd, network manager and ppp. While tracking down such issues can be fun, this case was more annoying than useful

Solution candidate

As in most of the cases, a bit of googling unveils that this problem also affects others. There is a bug report in launchpad, which is marked as resolved with a fix. Unfortunately, that was not applied to 18.04 although it is a long term release. Nevertheless, one can inspect the patch and find that adding a few lines to /etc/ppp/ip-up.d/0000usepeerdns should fix the issue. The point of the patch is to prevent the misbehaving DNS configuration scripts to run when network-manager initiated VPN connections are terminated.

Applying patches directly to the local file system is not my preferred option - I would rather repackage the affected ppp deb or use dpkg-divert to apply local changes in a way that plays nicely together with the packaging system and keeps my system easily manageable in the long run. However, for a quick verification, I have applied the required modification, and found it would not work per se.

Applied solution

Switching to plan B. Upon inspecting /etc/ppp/ip-up.d/0000usepeerdns once can clearly see that if resolvconf - the traditional way how Ubuntu and most Linux distributions would manage name resolution in previous releases - is installed, the problematic part of the script is not executed. I settled with this simpler and cleaner solution, installed the resolvconf package and with that the issue was resolved.