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 > _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
