wireguard.lists.zx2c4.com archive mirror
 help / color / mirror / Atom feed
From: Lee Yates <rainmakerraw@icloud.com>
To: "WireGuard@lists.zx2c4.com" <WireGuard@lists.zx2c4.com>
Subject: DNS fails after undetermined time in-tunnel
Date: Tue, 31 Dec 2019 18:49:07 +0000	[thread overview]
Message-ID: <ef68748c-4b72-3287-781f-52cb93483de1@icloud.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2745 bytes --]

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

[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 3849 bytes --]

[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

             reply	other threads:[~2020-01-03 15:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-31 18:49 Lee Yates [this message]
2019-12-31 19:24 ` DNS fails after undetermined time in-tunnel Lee Yates
2020-01-03 15:54   ` Jason A. Donenfeld

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ef68748c-4b72-3287-781f-52cb93483de1@icloud.com \
    --to=rainmakerraw@icloud.com \
    --cc=WireGuard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).