Wireguard not working after reboot, WAN having custom DNS of ISP

Version Openwrt: 22.03.2. Hardware: Asus AC51U

Having a simple subnet router config with Wireguard client. In order to prevent dns leaks, the WAN interface has custom DNS IP's of the ISP wireguard server/peer, as also defined in the Wireguard interface.

Noticed that after a reboot, the WAN connection cannot be established, and the Wireguard interface does not have a connection showing 0 packets.

This issue cannot be resolved by setting the correct system time.

What works - remove the custom dns ip's in the WAN interface, save & apply changes.
And then add the custom dns ip's again.

Anyone can confirm this issue? And have a simpler workaround/solution?

what are the custom DNSes, are they in some way related to the VPN tunnel ?

1 Like

Don't configure DNS on WAN.
If you want to use some custom DNS on your router - configure it in DNS forwardings in DNS server (DNSmasq) configuration.
If you see a need using some specific DNS for some domain(s) like your WG server - configure it in DNS forwardings as well.
For troubleshooting purposes you can enable Log queries in DNSmasq configuration.

1 Like

a noob here. can you give an example how to enter this in Luci. I tried but does not have desired effect of preventing dns leaks which works in the wan interface

1 Like

The DNS has to be reachable through the tunnel. An ISPs DNS is generally only accessible from inside their network, so it will be unreachable once you are tunneled to a public IP outside the ISP's network.

If you configured the wireguard peer as a name rather than a numeric IP, there will also need to be working DNS before the tunnel can start up.

Distinguish between a DNS problem and a general routing problem by trying to ping sites by their numeric IP, such as Numeric IPs should always work even if DNS is broken.

i agree there is a chicken and an egg situation, if the Wireguard peer is not an address, but a hostname. I use a hostname, because the wg peer does not have a public IP address.

On a reboot, the WAN is created. In order to create a tunnel, the WAN must first resolve the peer's hostname, which will fail because of the ISP's "internal" dns address, that the WAN is using.

Dealing with DNS changes for OpenWrt + WG is unfortunately not the most straightforward thing. If you're okay using a public DNS instead of the ISP's DNS, you should be able to resolve without issue.

Here is a thread that I started a while ago because I wanted to similarly change the DNS, but I ended up not bothering and simply using a public DNS for everything...

thanks for sharing. have a similar setup like yours.

i cannot prevent dns leaks with openwrt by setting custom dns at wan level:
1- dns of wireguard peer’s isp will show the servers of belonging to isp in ipleak.net
2- public dns like google or cloudfare will show servers in the wireguard peer’s country
3- not setting dns at wan level will show servers in country of openwrt router.

1 is the best option, can live with 2 without fiddling with the router after a reboot. 3 is not ok.

if i compare this openwrt wg solution to a raspberry pi linux wg solution (eg RaspAP), i see more flexibility in the pi’s solution with regards to leak prevention and resolving the wg peer’s dns name on demand, instead of on startup time of the wg interface.

but i’ll keep my openwrt solution to find out how reliable it is. besides i can run this thing on any old router at hand

thanks all for sharing your thoughts

I haven't run WG on a big linux distro (although maybe I'll do that sometime soon just so I can say I have), but on Mac, iOS, and Android, the DNS that should be used once the tunnel is up is super easy to specify and works properly.

I don't entirely understand why the implementation within OpenWrt can't do this same thing, but I do believe that there are valid technical reasons for this... I'm hoping that DNS when the WG tunnel is established can be specified more easily and directly in some future version of OpenWrt.

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