Similar problems have been reported in the past but I decided to start a new post as I am seeing this problem on current 3.212 beta firmware.
I am testing 3.212 beta 1 on a AR750s using a 2.4G WIFI WAN uplink, and 5G WIFI for my clients. I have it running as a Wireguard client with Internet Kill switch activated. Today I noticed that my clients were connecting to the router, but my router was not passing any traffic. Looking at the AR750s GUI showed my Wireguard connection was no longer connected and was showing a yellow indicator. Looking at the logread output, I can see in a 10 minute period the host router I am connected to dropped and reconnected several times over a 10 minute period, but I see no attempts to restart Wireguard after the WIFI connection became stable. I manually restarted the Wireguard client on the ar750s, and it reconnected to my Wireguard server and data started moving again.
I run the Wireguard server my AR750s connects to, and I use iptables to log new Wireguard connections. In this log I did not see any new connections attempted until I manually restarted Wireguard on the AR750s.
Should Wireguard restart after having WAN network issues? My past experience with OpenVPN on my GL iNet routers shows it automatically restarts. I would hate to have to go back to OpenVPN, but I need a reliable connection.
The previous GL iNet production firmware I was running on my AR750s was giving me so many problems that the router was not usable in my current environment, so I cannot say if the problem existed or not. I tried out the beta firmware after reading another user reported that it helped him with some similar issues on their AR750, in hopes I could use my AR750s in my current environment. Please see:
Before posting this report, I did a search of the forum, and there were several reports of problems with Wireguard reconnecting in some instances, but I could not find an exact match, so I created a new issue. I feel users need to report issues found in the beta releases if we expect them to be fixed in the production version.
If GL iNet engineering cannot fix the problem in the released version, I will probably just run OpenVPN while on travel, as it just works.
Just works is what I’m really looking for in a travel router
The main reason I wrote the post was to let @alzhao and is team of engineers know that there is a problem, as they may not see the issue in their test environment during the beta period. The fix for the AR750 in the current beta was due to @325i making multiple detailed reports of the problems they found in their AR750 in their specific environment to this forum, followed up by @alzhao and his team finding the root cause, and getting the fixes into 3.212.