and Sorry for my English translator.
I'm running OpenWRT on a Fritzbox3370 and want to connect via Wireguard client to a remote pfSense, which serves as a Wireguard server and is connected to a DSL connection with changing IP.
A DynDNS account is set up on the pfSense, which is entered in the OpenWRT Wireguard client.
The Wireguard connection works without any problems until the point at which the provider is forced to disconnect from the pfSense. After that, the Wireguard client request probably goes to nirvana until I restart the OpenWRT router/Wireguard.
The problem is known and there are also solutions for it under Linux.
Unfortunately, the description here refers to 'systemd', which unfortunately is not part of the OpenWRT standard. I don't know if there is a way to transfer this to the 'init.d' system.
Has anyone here in the forum had this problem before or can send me a link to it.
Maybe a simple cron job will suffice, but I don't know how to fix the problem with my limited Lunux knowledge.
Thanks in advance for any tip...
and sorry for the late reply.
I first had to fix my camera system via OpenVPN between pfSense and Fritzbox3370/OpenWRT.
The Wireguard trials just took too much time.
Now for my result...
I currently have a stable Wireguard tunnel running between pfSense (DynDNS-WAN) and a Linksys E4200v2 (OpenWRT) with WAN on an LTE USB stick.
Here 2 x CG-NAT is done by the provider and the stick hardly allows any modification.
After changing the port from 51820 to a lower port and changing the tunnel network to a network in the IP range 172.16.xx.x/24, although the latter was probably not responsible.
I suspect port 51820 is blocked by the provider as the standard port of Wireguard.
The tunnel is now running until the moment I restart the pfSense. I have not yet tried whether it survives a forced disconnection with an IP change on the WAN of the pfSense.
When restarting pfSense, I can only reactivate the tunnel if I restart the OpenWRT router as Wireguard initiator.
I tried using the page linked by @Pawel, unfortunately with little success.
I also don't understand exactly how this is to be used, the 'inner workings' of OpenWRT are still too suspicious for me, even though my Linux knowledge is at a fairly good level.
I went through the wireguard_watchdog script and found the problem. Somewhere along the way I forgot to activate persisent keep alive in the peer settings. After that it works as expected. The script checks if the peers have endpoints, are enabled and if the last handshake is more than 150 s ago. If all conditions are met, the wg tunnel command is rerun, hence, the dns is re-resolved.
Persistent keep alive is set to 25, so that can't be the reason.
So if the script does its thing as it should, a forced disconnection due to a power failure or a reboot on the pfSense as a WG 'server' should also lead to the automatic restart of the WG on the OpenWRT router.
Have I understood that correctly?
But it doesn't.
PS: Perhaps it would be better to 'provoke' a restart of the router with the script. The only question is whether the script would do that if there was a change, or whether there is another error here?
Since the problem only occurred sporadically, troubleshooting was not easy.
The pfSense as the remote station finally reported sporadic packet loss on the WG-GW.
The OpenWRT router registered a sporadic failure of the WAN-LTE connection.
In the end, the failures happened more and more often until the router no longer allowed a WAN connection at all.
Problem solved, new LTE stick has been ordered.
Thank you for your help.