For those using GL.iNet routers for remote work, ensuring your DNS isn’t leaking is crucial, especially when using VPNs like WireGuard or Tailscale. Leaked DNS requests could expose your browsing activity or location. Generally this is quite rare to happen, but there can be edge cases that could cause this to happen. It’s also not a given that your DNS traffic and associated location with that traffic is actively being monitored, but it’s best to assume the worst.
Why does DNS matter? DNS servers are responsible for translating website names into IP addresses. These servers are spread all over the world, and even if you’re using a VPN, a DNS leak can reveal your true location by sending requests outside your VPN tunnel. The Wireguard protocol uses a full tunnel VPN by default, so this should not happen especially if you have “Block Non-VPN Traffic” enabled on the client router.
Understanding DNS distance: The closest DNS server to you could be hundreds of miles away, but that’s not necessarily a problem as long as it’s still within the same country as your home server. So, don’t be alarmed if you see a DNS server that’s not super close to your server location.
How to test for DNS leaks: Use dnsleaktest.com. This tool is easy to use and provides a quick test to see if any of your DNS requests are leaking outside your VPN. Be sure your browser and potentially even your device’s DNS cache is cleared before testing.
Recommended DNS settings:
WireGuard: We can set the server router’s DNS settings like below. It’s generally best to avoid using your ISP’s DNS settings for privacy reasons. Also Cloudflare (1.1.1.1) normally has the best performance of all DNS options. Though it could vary if you don’t have a server near you (unlikely).
Now modify the client’s config file to point to your server for DNS (which can use the same settings as below). These will essentially do the same thing, but perhaps less routing confusion if you point directly to your Wireguard server IP.
To edit the profile config, go to Wireguard Client and edit the “DNS = ” line to equal your server IP (ex.10.0.0.1, or10.1.0.1in my case below).
Then, set the DNS mode to “Automatic”. This uses the DNS servers configured on your Wireguard server and ensures your server router’s DNS cache is checked before sending the DNS requests to whatever server you chose.
Tailscale: Tailscale automatically routes DNS requests through its servers, but you can override this by setting custom DNS servers in the Tailscale admin console, ensuring all traffic is routed securely.
For the client router settings, use Manual mode and set to Cloudflare and/or Google as a backup.
This is super helpful! Thanks for the post u/NationalOwl9561. Question about using cloudflare or google dns: wouldn’t it be obvious that I’m using a vpn to mask my location because they’re well known? I want to maintain stealth and security while ensuring 0 dns leaks.
Thanks for this, it’s something I’ve always been a bit unsure about how to best configure but everything here makes sense. Do you have recommendations for the other 2 DNS settings (both the client / server)?
EDIT: After reconfiguring my DNS to match that in the OP, I found that DNS queries on my client weren’t resolving unless the ‘Allow remote access LAN’ option was turned ON for the wireguard server, which makes sense but is easy to overlook.
Question for item #3. What should we see if the DNS leak test failed? I have only tested my Wireguard within the US and accessing the site shows my home IP address + home location.
If I already have Blocked non VPN traffic enabled on my client router, is it necessary to do step 4? I am asking because I don’t understand item #4 much and don’t want to mess up my already working Wireguard setup.
Hi, just a question, but with this configuration, are we sure that the DNS from tethering (and in my case from cellular) is not used?
there is a way to check?
thank you for this post. i have a few questions about step 4 in this post and your response to an earlier comment
On the client router - Override DNS Settings of All Clients is turned on based on your guide. Is “Allow Custom DNS to Override VPN DNS” recommended to be turned on or off?
by default the DNS of the wireguard profile when created from the server (flint) is 64.6.64.6 but you are saying to change it to the server ip (default 10.0.0.1) in the configuration when you set up the client (beryl) otherwise performance is reduced. However if you force all traffic through the vpn (via block non-vpn traffic) wouldnt the DNS that is used be the server DNS (flint)? isnt the result the same? how does it impact speed?
Since I have wireguard configurations set up already before this guide - the default DNS of the wireguard profile is 64.6.64.6 when created on the server (flint) , when you look at the wireguard configuration from the server setting and compare it to the configuration on the client would a mismatch unless i edit the profile on the server side. Im guessing this should be done - correct?
Also to be able to see the setting of “automatic dns” i have to turn off the usage of ad-guard. But if i have adguard on - wouldnt the default setting also be automatic? Obviously adguard is not as important for location privacy when nomading but just wanted to double check that i should have it turned off to ensure the settings are correct.
Now modify the client’s config file to point to your server for DNS (which can use the same settings as below). These will essentially do the same thing, but perhaps less routing confusion if you point directly to your Wireguard server IP.
To edit the profile config, go to Wireguard Client and edit the “DNS = ” line to equal your server IP (ex. 10.0.0.1, or 10.1.0.1 in my case below).
Then, set the DNS mode to “Automatic”. This uses the DNS servers configured on your Wireguard server and ensures your server router’s DNS cache is checked before sending the DNS requests to whatever server you chose.
Where am I doing this? On the server side or client side
Am I editing the config file itself to match the Server IP?
Slightly unrelated but there are a few other things I’ve done to mask location:
Address reservations on the client router for specific MAC addresses. I’ve seen weird things happen when renewing a DHCP lease. This essentially disables DHCP as you get a static IP.
Disable WiFi entirely. This is a must. For example, on Macs, Apple tracks your location from nearby WiFi networks, even if you’re not connected to them. You must switch off WiFi and keep it off otherwise your company can still track you.
Nobody is looking at Google or Cloudflare DNS servers and thinking… “hmm this is suspicious”. In fact, if they saw your home ISP and by chance didn’t recognize them or their servers they’d be MORE suspicious.
But let’s be real, nobody in IT is looking at your DNS traffic in the first place.
I have the bottom one enabled for both server and client but it won’t really do anything on the client router because it’s set to Automatic mode and on the server it definitely doesn’t do anything because it IS the host, not connecting to a VPN as a client.
But if you ever needed to troubleshoot DNS settings, you could switch to Manual mode on the client and have this enabled to override the VPN server DNS.
Regarding your comment edit, this is why I said at the end of my post to enable remote access LAN on the server settings. Sorry I didn’t make this more clear
If the DNS leak test fails it means you would see DNS servers used near your client router location and not the ones you specified to be used by the VPN server. So if you specified Google servers, you should see Google. Same for Cloudflare. Near the server.
No, you don’t have to do Step 4. It’s just recommended, but as mentioned in the beginning, all of your traffic including DNS traffic is already going through the tunnel, so it’s not going to be exposed anyway even if the VPN failed since you turned on the “kill switch”. However, your VPN performance will be drastically reduced if you don’t follow Step 4 to point the DNS to your server.
“Allow Custom DNS to Override VPN DNS” isn’t going to be an option because you’re setting the client to “Automatic” which means there is no “custom DNS”. And on the server side, you’re not connecting to any VPN server so it doesn’t do anything.
You’re right that in both cases the DNS traffic goes through the VPN tunnel first then resolves at the server end. The difference is by changing the DNS in the VPN client config to the VPN server’s IP, you take advantage of the DNS caching at the VPN server, which can result in faster DNS lookups since the server can return cached results without querying the external DNS servers again.
The client profile on the server doesn’t matter. That’s just for exporting. As long as the config file is correct on the client, then you’re good.
I’m not familiar with how Adguard and GL.iNet works since I’ve never used it sorry.
As it says, edit the client’s WireGuard config profile. This is located under WireGuard client. Edit the DNS line to be equal to your WireGuard server IP (this can be found on the WireGuard Server page of your server router).
It’s both Windows and Macs where location services uses Wi-Fi geolocation. I think at least on Windows, if you disable Location Services in Windows settings then Wi-Fi geolocation won’t happen and you could possibly use Wi-Fi. I’m not 100% sure but from reading the manual that’s what it seems to indicate.
