VPN client doesn't work after reboot

So I setup a Pi4 with Dietpi and control it thru ssh. I installed wireguard and use it as a client with an external vpn provider. Everything’s been working fine, but I did a reboot yesterday, and now it won’t work.
wg command shows a working connection but I cant use uit as a client from my other devices on the LAN. I don’t know but my guess is it has something to do with the firewall rules?
I set up a couple of IPTABLES rules following this guide: https://mgnk.it/2019/03/raspberry-pi-as-a-vpn-gateway-using-wireguard/
I also did a sysctl on the wireguard and sysctl netfilter.-persistent so both are supposed to start after a reboot, right?

Could it have something to do with the order they start up? Maybe the iptables rules doesn’t take effect on the wireguard client if it starts before the iptables rules are implemented? I did try to do a wg-quick down and up but there’s no difference…
If I input the IPTABLES rules again from the above link, everything works, so something with those rules doesn’t work with wireguard after reboot.
Appreciate any help on how to move forward in the matter…


many thanks for your message. Did you checked if your iptables rules are still present after reboot? I guess you would need to make them boot persistent using something like iptables-persistent. I know it’s possible to add iptables rules together with Wireguard Server config file. But I’m not sure on Client config file.

Yes, i did:
sudo systemctl enable netfilter-persistent
following the guide i mentioned.
I will take a look. They are probably not active, at least not for wireguard.
I’m pretty sure i read somewhere about timing issues after a reboot? Something about one should delay the startup of wireguard some way so all the nat rules have time to be implemented before wg starts… can’t find it now tho…

You could make service depending on each other. For testing, you could deactivate Wireguard and check if iptables-persistent will bring back your configuration. If not, it’s already failing at this step.

I would also wonder if ip4 forwarding hasn’t survived the reboot and is now disabled?

See here for how to check and if needed enable.

you could check this by running sysctl net.ipv4.ip_forward. It should return 1

Thanks! I’ll investigate first thing tomorrow…

I had the same, but this method still work