WireGuard DNS after latest upgrade


since the latest upgrade, my local DNS server specified in WireGuard has stopped working. After recovering the last version everything works fine again. What could that be?

Thank you

Can nobody help here?

If the issue still occurs:
When connecting a client to the VPN, is it possible to connect via bare IP to some external address, so really only DNS resolving fails?

yes IP addresses work perfectly, only the DNS resolving does not work anymore.

It is the client that cannot resolve hostnames, not the server, right?

Could you please try it with the new kernel and WireGuard versions:
(you are on RPi, right?)

apt upgrade
dpkg-reconfigure wireguard-dkms

I already tried it with the new kernel and WireGuard, it did not work either.

I tested it now with the update from 6.21.1 to 6.24.1, unfortunately it does not work here either. Now I can only call external pages, local addresses work neither via DNS nor via the direct IP address.

I am not on an RPI, I am on a virtual machine on an ESXi 6.0.

I am now back to version 6.21.1 with the WireGuard version 0.0.20190406 (currently the version would be 0.0.20190601), everything works fine here.

What can I do to update to the latest version of DietPi?

I tried again with the update to version 6.24.1 and it did not work again. However, I noticed that the service for WireGuard has not started after the update and can not be started anymore. So it does not work anymore, but why can not the service be started and how can I fix it?

Note that it is essential that you recompile the WireGuard module after every kernel upgrade:

apt full-upgrade
dpkg-reconfigure wireguard-dkms

You could do a dietpi-backup and run the above two commands to upgrade both and see if your issue related to the WireGuard/kernel upgrade or because of the DietPi-Update.

In case the service fails, please paste:

journalctl -u wg-quick@wg0
ip a

And check if the module has been loaded successfully:

lsmod | grep wireguard


The kernel upgrade is not the problem, I’ve done the update in 6.21.1 and WireGuard still works fine. The command systemctl status wg-quick@wg0.service probably shows the cause of the problem.

root@WireGuardPi:~# systemctl status wg-quick@wg0.service
wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2019-06-10 15:52:51 BST; 2min 46s ago
Docs: man:wg-quick(8)
Process: 1434 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=255)
Main PID: 1434 (code=exited, status=255)

Jun 10 15:52:51 WireGuardPi wg-quick[1434]: [#] ip link set mtu 1420 up dev wg0
Jun 10 15:52:51 WireGuardPi wg-quick[1434]: [#] ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o $(sed -n 3p /DietPi/dietpi/.network) -j MASQUERADE
Jun 10 15:52:51 WireGuardPi wg-quick[1434]: [#] sysctl net.ipv6.conf.wg0.forwarding=1 net.ipv6.conf.$(sed -n 3p /DietPi/dietpi/.network).forwarding=1
Jun 10 15:52:51 WireGuardPi wg-quick[1434]: net.ipv6.conf.wg0.forwarding = 1
Jun 10 15:52:51 WireGuardPi wg-quick[1434]: sysctl: cannot stat /proc/sys/net/ipv6/conf/NONE/forwarding: No such file or directory
Jun 10 15:52:51 WireGuardPi wg-quick[1434]: [#] ip link delete dev wg0
Jun 10 15:52:51 WireGuardPi systemd[1]: wg-quick@wg0.service: Main process exited, code=exited, status=255/n/a
Jun 10 15:52:51 WireGuardPi systemd[1]: Failed to start WireGuard via wg-quick(8) for wg0.
Jun 10 15:52:51 WireGuardPi systemd[1]: wg-quick@wg0.service: Unit entered failed state.
Jun 10 15:52:51 WireGuardPi systemd[1]: wg-quick@wg0.service: Failed with result ‘exit-code’.

Does this information help?

Ah indeed, it seems that the active network device could not be identified on boot.

Please check: sed -n 3p /DietPi/dietpi/.network
It seems to contain “NONE”.
Try: /DietPi/dietpi/func/obtain_network_details
Then retry sed -n 3p /DietPi/dietpi/.network, if it shows the correct interface.
If so, then systemctl restart wg-quick@wg0 should fix the state.

I think we should run this script to update network info as ExecStartPre to the WireGuard systemd service, in case on boot waiting for network exceeds the default 10 seconds timeout.

I have executed the commands as described, unfortunately always “NONE” is returned. I have set in Dietpi-config, the setting when booting to wait for network, synonymous unfortunately brings the same feedback. :thinking:

That is strange, can you paste: ls -Al /sys/class/net/

It looks like this under 6.24.1
ls -Al /sys/class/net/
insgesamt 0
lrwxrwxrwx 1 root root 0 Jun 24 07:04 eth0 → …/…/devices/pci0000:00/0000:00:11.0/0000:02:02.0/net/eth0
lrwxrwxrwx 1 root root 0 Jun 24 07:04 lo → …/…/devices/virtual/net/lo

It looks like this under 6.21.1
ls -Al /sys/class/net/
insgesamt 0
lrwxrwxrwx 1 root root 0 Jun 24 07:08 eth0 → …/…/devices/pci0000:00/0000:00:11.0/0000:02:02.0/net/eth0
lrwxrwxrwx 1 root root 0 Jun 24 07:08 lo → …/…/devices/virtual/net/lo
lrwxrwxrwx 1 root root 0 Jun 24 07:08 wg0 → …/…/devices/virtual/net/wg0

Sorry for late reply.

Okay the network device is there. It is expected that wg0 is not there as the WireGuard service failed.

Lets go through it what /DietPi/dietpi/func/obtain_network_details does to debug why it does not print the existint eth0 interface to /DietPi/dietpi/.network.

  1. It exits when it finds itself running and in case exits. So if one instance is hanging (e.g. from boot), that would explain it:
    pgrep ‘obtain_network_details’
  2. It scrapes the IP address and checks is the connection is “UP” from: ip a s eth0

attached the result.

state UNKNOWN is the issue. Hmm network/internet works well with this? What does ethtool eth0 say about link connection?

And could you print ip r to check if default route is set, which might be then the safer check for active adapter.

As a quick workaround you can do:

sed -i 's/UP/\(UP\|UNKNOWN\)/g' /DietPi/dietpi/func/obtain_network_details
systemctl restart wg-quick@wg0


attached the result.
Quick workaround solved the problem, no it works.

Thank you for your help.

Okay thanks for testing, great it works.

Hmm now I am thinking how to find a solution code wise. Actually we implemented the “UP” check just a short time ago due to issues/wrong entries if this was skipped. And now we have a case where it is exactly the other way round.

Strange that ip does not recognise it as “UP” as the default route is there and ethtool also shows it as connected :thinking:.

ethtool cannot be used regularly since it yeah only works for Ethernet of course and also the connection state does not imply that it is connected to the gateway or even has in IP assigned.
Default route is already safer, but this changes (reasonably) when you’re installing a VPN client, so is not 100% failsafe as well.
But ip r should always list the gateway link, so if we check for the word " via ", it should be safe.

Ah no, default route stays:

root@VM-Stretch:~# ip r via dev tun0
default via dev eth0 onlink dev tun0 proto kernel scope link src via dev tun0 via dev eth0 dev eth0 proto kernel scope link src
root@VM-Stretch:~# ip r s
default via dev eth0 onlink

Many thanks for your answer. I do not know if this information is still important, but the line with “via” shows the default route.

Yeah perhaps we should use this is more reliable method to determine the main active network device. But I want to assure that the default route also stays the same when using WireGuard as VPN client (you use it as server).

But that is something I will not touch for v6.25 any more. So when you run dietpi-update, remember to reapply the workaround. I will then have a closer look for v6.26 where I anyway plan some deeper rework of our network setup.