Hey everyone,
unfortunately my wireguard (home-)server is weirdly broken since the latest udpate.
I can still get a handshake and can connect to devices in LAN, but there is no connection to WAN. I changed nothing in my configs, so the routing is the same which was functionally before. However, I noticed a warning when running systemctl status wg-quick@wg0.service:
Warning: The unit file, source configuration file or drop-ins of wg-quick@wg0.service changed on disk. Run 'systemctl daemon-reload' to reload units.
● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/wg-quick@wg0.service.d
└─dietpi.conf
Active: active (exited) since Thu 2021-05-20 17:18:22 BST; 6min ago
Docs: man:wg-quick(8)
man:wg(8)
https://www.wireguard.com/
https://www.wireguard.com/quickstart/
https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
Process: 464 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCCESS)
Main PID: 464 (code=exited, status=0/SUCCESS)
May 20 17:18:22 DietPi wg-quick[464]: net.ipv4.conf.wg0.forwarding = 1
May 20 17:18:22 DietPi wg-quick[464]: net.ipv4.conf.eth0.forwarding = 1
May 20 17:18:22 DietPi wg-quick[464]: [#] sysctl net.ipv6.conf.$(mawk 'NR==3' /run/dietpi/.network).accept_ra=2
May 20 17:18:22 DietPi wg-quick[464]: net.ipv6.conf.eth0.accept_ra = 2
May 20 17:18:22 DietPi wg-quick[464]: [#] sysctl net.ipv6.conf.wg0.forwarding=1 net.ipv6.conf.$(mawk 'NR==3' /run/dietpi/.network).forwarding=1
May 20 17:18:22 DietPi wg-quick[464]: net.ipv6.conf.wg0.forwarding = 1
May 20 17:18:22 DietPi wg-quick[464]: net.ipv6.conf.eth0.forwarding = 1
May 20 17:18:22 DietPi wg-quick[464]: [#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o $(mawk 'NR==3' /run/dietpi/.network) -j MASQUERADE
May 20 17:18:22 DietPi wg-quick[464]: [#] ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o $(mawk 'NR==3' /run/dietpi/.network) -j MASQUERADE
May 20 17:18:22 DietPi systemd[1]: Started WireGuard via wg-quick(8) for wg0.
I ran the suggested systemctl daemon-reload, which resolves the warning, however the problem of no connection is still present.
I also have pihole and unbound installed, if that helps.
I hope someone already had the problem and can drop the solution to this 
If you can connect inside you local network it is not an issue if WiteGuard server.
Pls check if you are using correct DDNS on your client pointing to correct external IP address of your router.
Hey Joulinar, always a pleasure
Hm, but wouldn’t I even able to connect to the server (and therefore the local network), if the DDNS had the wrong IP address?
Anyways, I checked and my DDNS points to the correct external IP address. However, I don"t use it with the external IP address of the router but the IPv6 address of my Raspi using ddclient. Worked like a charm in the past and as I said, I haven"t changed any config files.
Well if you are able to connect locally the server seems to be fine and Wireguard is not broken in general. Just for testing you could try using IPv4 from external. Just to see if it is working.
Ah well, then something seems to be broken or interferes with the configuration after the 7.1.2 upgrade…or it wasn"t the 7.1.2 upgrade but regular apt upgrade, I’m not sure. But in my understanding, it has to be one of those two reasons as I didn"t change anything.
I can"t check IPv4 unfortunately, as my provider only supports DS Lite.
DietPi themselves is not doing anything on Wireguard and his server configuration. As well you are able to connect locally. Means the server is running. Did you checked if the IPv6 address changed? Did you test connect from local network using IPv6 from your DietPi device.
ip a
should show the actual IP address
Not sure if it helps, but I had a similar issue after the upgrade to 7.1.2 and reinstalling unbound via dietpi-software resolved it for me.
For some reason it wasn’t recognised as installed software.
Also, after reinstalling, the port of the local upstream DNS was set correctly to 5335 from 5353 before (within pihole).
T
I doubt that this has anything to do with it. Unbound is responsible for DNS resolution. But in this cause we already fail to get the basic VPN connection established.
does it mean you see the handshake on your Wireguard server using wg, even on full tunnel. I was under the impression you could not connect at all and there was no handshake.
Disclaimer: Sorry, I deleted my previous answer because I wanted to recheck something. I didn’t make a backup of the text so I’m sorry I can’t provide the same text again.
Yes, I can see the handshake also on full tunnel. So, I can connect, but only have access to the server LAN and are not forwarded to WAN.
However, I found the very strange solution. I played now with the DDNS record on my DDNS provider. Just copied the IP address given from ip a and added it under the existing one for comparison. It was the same. Then deleted the old record, so only the new one was handed out on request (which is the same as the old one 
). Now everything works.
Maybe I’m going crazy or just overlooked something small. But I can’t explain why it works now 
But I guess, it wasn’t a wireguard or DietPi update problem then, but a problem with my DDNS provider.
but a problem with my DDNS provider.
Probably the address got corrupted on their end. We never will find out. Do you regularly update your DDNS record using a script or update URL?
Yes, I update frequently (every 24 hours) using ddclient. Before you ask: Yes the problem persisted longer than 24 hours 
Yeah and often it’s the small things which get overlooked, I guess you have quite the eye for those things by now
Feels weird not being able to provide a proper solution to the problem from my side for future solution seekers…
However: much thanks again to Joulinar for providing a helpful (and idea rich) hand!
you’re welcome, enjoy the rest of the day or have a good night
