There is a known issue where the router connects as a wireguard client to a server with a DDNS endpoint and the ip changes, the connection is not restored. This leads to serious issues within the whole network.
I am far from being an expert with OpenWRT scripting or bash scripting in general, so contributions are welcome. I hope GL.iNet provides a native solution soon.
I believe you have not understood the issue I am referring to. If I set up a Wireguard client on my gl.inet router, and the endpoint of the wireguard server is a DDNS, the flint will not detect the ip change of the server, so it will not re-resolve and reconnect, it will remain in a broken state.
I see. The premise is that the endpoint of the VPN client profile uses a domain name (GL DDNS domain).
Is the problem reproduced in a scenario like this:
if the VPN server's device WAN IP is updated (change a new one), the GL DDNS service also is ok (i.e., it updated the new IP, normal), and at this point, the VPN client is disconnected due to the IP update, but there's a problem with the DNS service of the client device, it hasn't been able to domain-resolve the endpoint's domain anymore?
I have tried to reproduce in my router, but it seems cannot reproduce, even the server WAN public IP changed. The client will indeed be disconnected, but then after GL DDNS updates the IP, the VPN connection will also be established, means the DNS of the client device is normal during it disconnected the VPN (only resolve the VPN domain at that time, not leak the clients DNS).
The WireGuard server is not on a gl-inet router. There is no gl-inet router at the server’s side. The server is a different, vanilla openwrt router with duckdns.
The client is a Flint2. The Flint2 is set up as a WireGuard client connecting to the WireGuard server by using the endpoint xxxx.duckdns.org. Also, the VPN policy on the Flint2 is “Based on target Domain or IP”. Last but not least I’m also using Adguard Home on the client.
When the WireGuard server changes its public IP, until I disconnect and reconnect manually (or reset the Flint 2), all clients of my Flint 2 router cannot access the internet. I am not completely sure, but there is a chance that it’s not internet that that’s not working, but domain resolution instead.
I wonder whether GL.iNet has checked the issue I mentioned and if there is any official fix scheduled in the pipeline. By the way, the same issue occurs even if the Wireguard server is under a glddns dynamic dns domain.
To sum up, my configuration is:
Wireguard client (MT6000 Flint 3):
Adguard home set up with default settings (AdGuard Home Handle Client Requests is DISABLED)
Wireguard client configuration to connect to a wireguard server that has been set up on the remote GL.iNet (MT6000 Flint 3) using the glddns address that has been set up on that remote GL.iNet device.
VPN Policy set up "VPN Policy Based on the Target Domain or IP" with some IPs and Domains.
If the remote GL.iNet goes offline and / or it's public IP is changed, then:
DNS resolution stops working in general on my local network (where the wireguard client GL.iNet is)
Even if the remote GL.iNet goes back online and / or it's new IP is updated @ glddns service, the connection is not restored.
Possible points of solution:
Make dns resolution only for the specific domains of the vpn policy go through the wireguard vpn tunnel
Let user choose if they want their dns to NOT go through the vpn tunnel at all (leak)
Integrate something like the wireguard watchdog that I have implemented within the GL.iNet firmware so that it sticks when firmware upgrades occur.
The R&D is developing and improving VPN-related functions, requirements and issues.
We will consider improving it base on this point, DNS split traffic, to resolve the issue of all DNS traffic completely goes through VPN (when ADG is enabled, and proxy mode is based on device MAC or domain name, IP).