Ran into an issue after rebooting my router. Wireguard would not connect. Backed up my current config and restored from a backup and everything was fine. TL;DR - After removing the CIDR list from Allowed Clients and rebooting the router, Wireguard connects successfuly.
Question is - why?
I had made some changes to AdGuard since my last backup and started going through what i could remember. I made update to client entries, custom filters, upstream DNS, and the allowed client list. After some try/reboot/fail, the Allowed Clients list under Settings → DNS Settings was the culprit.
<< EDIT - Changed this to 192.168.8.0/24 for simplicity >>
.1 is my GL-MV1000
Nothing out of the ordinary. I tried removing different entries (starting with 192.168.8.1/32) and rebooting each time. Once the list was empty, wireguard connected on reboot.
Any ideas? I’d certainly like to implement this as external IPs are using me for DNS.
If I have any entries on that list, Wiregard fails to connect. If I reboot the router with Allowed Clients blank, wireguard will connect. I am able to add entries to Allowed Clients after boot and it works as expected. The problem case here is that if I lose power or have to reboot the router I must remove the cofiguration, reboot the router again, then add my settings to Allowed Clients again manually.
Can you try removing the Allow Clients, connect Wireguard, then check the AdGuardHome Query Log to see if there are any DNS requests that are not in the 192.168.8.0/24 subnet?
I do not work for and I do not have formal association with GL.iNet
Quite a few, actually. This was the reason I implemented this in the first place. The Allow Clients configuration was in place for about a week before I had to restart to my router (and subsequently discovered this problem) and all requests were from 192.168.8.x – so it was working well.
Maybe some of those DNS requests from IP’s that are not in the 192.168.8.0/24 subnet are preventing Wireguard from connecting when they cannot be resolved.
I do not work for and I do not have formal association with GL.iNet
With CIDR ranges in the Allow Clients list, Wireguard will not connect on boot
Without CIDR ranges in the Allow Clients list (empty), Wireguard will connect on boot. External DNS requests show in my log immediately
After booting w/o CIDR ranges in the Allow Clients list (empty) and Wireguard connected successfully, I am able to add CIDR ranges to the Allow Clients. This DOES prevent external IPs from using my DNS server
This seems like a bug unless there is something that is happening/not happening that is beyond my scope of knowledge.
…not too sure about your actual config but have you already tried
using CIDR only in WG config? What WG doesn’t allow won’t be forwarded to your local DNS (that was rather a workaround).
using the IP address of us5854.[…] in WG-client config (this is just to test, I guess you cannot resolve “us5854.[…]” to an IP address. if so we had to look at your WG-clients DNS config instead the WG-config)
Yes, they do filter - but only DNS, nothing else (and not by actually filtering DNS-traffic but by providing a DNS resolver that selectively answers - even mandatory DNS is nothing else than forwarding DNS traffic to the DNS resolver which answers it).
Yes. Of course I know since I am running AdGuardHome in Docker on my Synology NAS. My statement was “filter the Wireguard traffic”, which is not incorrect.
I do not understand what you are trying to prove, but I do not think it helps the OP any, so I will not continue this.
I do not work for and I do not have formal association with GL.iNet
It is 100% incorrect.
AGH cannot filter anything else than DNS requests.
So the only possibility, that AGH is the culprit in this threads issue, is that AGH blocks the DNS resolve of us5854.nordvpn.com.
I am not “trying to prove” anything but trying to keep OP from following wrong leads.
BTW, @kuzak : Already tried if the nonworking config suddenly works when you replace us5854.nordvpn.com) by its actual IP (152.89.204.162 RN) in the VPN client config?
