DNS fails after undetermined time in-tunnel

[Lee Yates]

Further to the below, I have discovered after sending the original
message (typical!) that resolvconf doesn't appear to be being called
correctly, at least on Void.

> resolvconf -a mullvad -m -0 -x
> No file given via stdin

The DNS entry in /etc/resolv.conf stays at the original system DNS and
isn't changed to reflect the WireGuard .conf file.

However after noticing this and issuing 'resolvconf -u' manually once
the tunnel is up, openresolv/resolvconf correctly updates
/etc/resolv.conf with the tunnel's supposed DNS (from the .conf).

> $ sudo resolvconf -u
> $ sudo cat /etc/resolv.conf
> # Generated by resolvconf
> nameserver 193.138.218.74

As I said in my first message, this isn't Void Linux specific and people
(including me) are experiencing the same issue on systemd based systems,
but hopefully it's a useful pointer. Again, I hope this is helpful.

Best wishes,

Lee Yates


On 31/12/2019 18:49, Lee Yates wrote:
> Hi,
> 
> I hope everyone had an enjoyable festive period.
> 
> I have posted this issue on the /r/WireGuard subreddit, and several
> Linux people responded that they are also experiencing it. As such I'm
> posting here 'properly'.
> 
> For a while now, I have noticed that a WG tunnel on my Linux machines
> will at some point lose DNS. It doesn't matter what the DNS was set to
> in the .conf (i.e. VPN provider's own, my own local resolver on a Pi,
> Cloudflare, whatever) - after a seemingly arbitrary time DNS will just
> stop working whether in a browser, CLI or elsewhere. For example:
> 
>> $ update
>> Password: 
>> [*] Updating `https://alpha.de.repo.voidlinux.org/current/x86_64-repodata' ...
>> ERROR: [reposync] failed to fetch file `https://alpha.de.repo.voidlinux.org/current/x86_64-repodata': Transient resolver failure
> 
> Only taking down the tunnel and bringing it back up will resolve the
> issue, at least until it recurs again a short while later. Curiously
> though, wg-quick reports that there's no such process during the
> take-down, but it does nonetheless disconnect it. Reconnecting does, as
> I said, work fine for a while again.
> 
>> $ sudo cat /etc/resolv.conf
>> nameserver 192.168.2.12
> 
>> $ wg-quick down mullvad
>> [#] ip -4 rule delete table 51820
>> [#] ip -4 rule delete table main suppress_prefixlength 0
>> [#] ip -6 rule delete table 51820
>> [#] ip -6 rule delete table main suppress_prefixlength 0
>> [#] ip link delete dev mullvad
>> [#] resolvconf -d mullvad -f
>> [#] iptables-restore -n
>> [#] ip6tables-restore -n
>> [#] ip route del 192.168.2.0/24 via 192.168.1.1
>> RTNETLINK answers: No such process
> 
> I am currently in Void Linux with WireGuard version 20191219 (the latest
> in the repo). Void has openresolv (3.9.2_1) installed also, by default.
> Because Void uses runit rather then systemd, there's no access to the
> wg-quick@ system service. As such I am bringing up and taking down the
> connection manually with wg-quick up/down. However I get the same
> behaviour on Ubuntu 19.10, Arch Linux and Fedora 31 which all use
> systemd and the related wg-quick@ service (and resolvconf instead of
> openresolv).
> 
> I have also tried adding a PersistentKeepalive = 25 to my .conf with no
> effect either way. My home router is actually a repurposed Dell Optiplex
> Core i7 x64 machine with Arch Linux installed, and WireGuard has never
> needed NAT keepalive on my network before (nor did enabling it change
> this DNS drop behaviour). Finally, I have tried several WireGuard
> providers including Mullvad, TunSafe, AzireVPN and a manual VPS install
> - all have the same DNS failure after a short while.
> 
> I don't know how to start debugging this, but hopefully I've provided
> enough to help someone get an idea (or provide me further steps to help).
> 
> Best wishes,
> 
> Lee Yates
>