wireguard.lists.zx2c4.com archive mirror
 help / color / mirror / Atom feed
* DNS fails after undetermined time in-tunnel
@ 2019-12-31 18:49 Lee Yates
  2019-12-31 19:24 ` Lee Yates
  0 siblings, 1 reply; 3+ messages in thread
From: Lee Yates @ 2019-12-31 18:49 UTC (permalink / raw)
  To: WireGuard

[-- 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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: DNS fails after undetermined time in-tunnel
  2019-12-31 18:49 DNS fails after undetermined time in-tunnel Lee Yates
@ 2019-12-31 19:24 ` Lee Yates
  2020-01-03 15:54   ` Jason A. Donenfeld
  0 siblings, 1 reply; 3+ messages in thread
From: Lee Yates @ 2019-12-31 19:24 UTC (permalink / raw)
  To: WireGuard

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: DNS fails after undetermined time in-tunnel
  2019-12-31 19:24 ` Lee Yates
@ 2020-01-03 15:54   ` Jason A. Donenfeld
  0 siblings, 0 replies; 3+ messages in thread
From: Jason A. Donenfeld @ 2020-01-03 15:54 UTC (permalink / raw)
  To: Lee Yates; +Cc: WireGuard

Interesting bug. According to the man page, the -u should already be
implicit when doing -a, since the contents should be different.

Can you look to see where in the resolvconf script it bails out? Maybe
stick a `set -x` at the top or something similar?
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-01-03 15:55 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-31 18:49 DNS fails after undetermined time in-tunnel Lee Yates
2019-12-31 19:24 ` Lee Yates
2020-01-03 15:54   ` Jason A. Donenfeld

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).