Hello,
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?
Niwre
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.
Niwre
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
@MichaIng
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?
Niwre
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)
man:wg(8)
https://www.wireguard.com/
https://www.wireguard.com/quickstart/
https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8
https://git.zx2c4.com/WireGuard/about/src/tools/man/wg.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?
Niwre
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.
@MichaIng
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. 
Niwre
That is strange, can you paste: ls -Al /sys/class/net/
@MichaIng
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
Niwre
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.
- 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’ - It scrapes the IP address and checks is the connection is “UP” from: ip a s eth0
@MichaIng
attached the result.
Niwre
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
/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.
Niwre
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 .
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
0.0.0.0/1 via 10.8.0.1 dev tun0
default via 192.168.178.1 dev eth0 onlink
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.9
128.0.0.0/1 via 10.8.0.1 dev tun0
185.220.70.210 via 192.168.178.1 dev eth0
192.168.178.0/24 dev eth0 proto kernel scope link src 192.168.178.29
root@VM-Stretch:~# ip r s 0.0.0.0/0
default via 192.168.178.1 dev eth0 onlink
@MichaIng
Many thanks for your answer. I do not know if this information is still important, but the line with “via” shows the default route.
Niwre
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.