Wireguard + DNS in 21.02.x

Hi all -

I was looking at the DNS settings within Wireguard for 21.02 and it looks like DNS does indeed leak. When I specify the DNS with Wireguard on my Mac or iPhone, that DNS server replaces the other(s) that have been specified in the system, thus preventing leaks. Not so for OpenWrt, AFAICT. I've been reading a number of threads on this topic which workaround the issue by changing some dnsmasq settings (namely setting it to ignore the peer advertised DNS, manually specifying the servers, and using a script to change these settings on if up/down for the WG tunnel if this needs to be somewhat dynamic).

I also found this issue filed as a bug, but this bug was closed because (if I understood it correctly and summarize it properly) it was determined that replacing the DNS address would be inconsistent with the operation of all other interface protocols handlers and therefore would really need to be addressed in the OpenWrt base first.

So, all of this to ask... is this still the case? Are there any more simple and/or elegant methods to replace the DNS servers when the WG tunnel comes up (and goes down)? My travel router is a road-warrior setup with 3 different endpoints for flexibility (all 3 are residential internet connections).


1 Like

There are currently several methods to solve DNS leak:

  • Set up a public upstream DNS provider with VPN gateway redirection enabled on the router, so all traffic including DNS will be routed to the VPN as soon as it connects.
  • Enable split DNS and advertise public DNS to clients, so client's DNS traffic is routed directly to the VPN bypassing the router's DNS, which mostly becomes irrelevant.
  • Selectively forward the VPN endpoint domain to public DNS, and the rest DNS traffic to resolvers configured on the VPN interface, removing resolvers from all other interfaces.
  • Configure hotplug to switch DNS dynamically based on the VPN connection status.

Each method has its pros and cons, so it depends on your use case which one fits better.

Actually netifd should support DNS metric, which can change the order of upstream resolvers, but it cannot prevent DNS leak.
It would be great if someone patches it to support negative values to replace resolvers on other interfaces similar to NetworkManager.

1 Like

Thanks @vgaetera for the answers.

So I tried playing with the DNS weight parameter, but that didn't seem to do much. I set the WAN to (in the wan interface configuration) and then WG DNS to the DNS of the remote network (I connected to my father's network from my home)... my test was using nslookup for a host in his network using his router's DNS. This works flawlessly when locally connected to his network and also when I use WG on my Mac to connect from my home. But no matter what I did, nslookup would always fail because the upstream resolver was never actually the one defined in the WG configuration. I did see the WG specified DNS in /tmp/resolv.conf, but it never seemed to use it, regardless of the DNS weights assigned to the WAN DNS and the WG DNS.

My ultimate goal would be as follows:

  • Use DHCP advertised DNS servers and/or a standard public resolver when the tunnel is not active.
  • Use a standard public resolver and/or the resolver on the target network when the tunnel is active.
  • It would be great to be able to have local DNS for the far endpoint so I can reach resources using hostnames. Split-horizon is okay, too, provided it is with a public DNS server and the resolver on my endpoint network.

Obviously the simple solution is to use a public resolver like Google or Cloudflare for everything, but I want my configuration to be more flexible in case any of those are blocked when I'm on the road somewhere. I don't want to have to mess around with the config until I get something working.

Dnsmasq periodically queries all listed resolvers ignoring their priority and then uses the fastest one for a period of time, so you cannot set up split DNS with just interface settings.
If you decide to go with split DNS, then configure Dnsmasq like this:

Remote LAN hostnames can be resolved with properly configured search domains on the client side and selective DNS forwarding on OpenWrt:


This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.