No DNS after enabling wireguard client connection

Hi,
I'm running this router that is based on OpenWrt 21.02-SNAPSHOT.

I added two wireguard client configurations; one to my home router (AVM FRITZ!Box) provided by ISP, and the other to a commercial VPN provider.

Here's the configuration of IVPN:

[Interface]
Address = 172.21.xxx.xxx/32,fd00:4956:504e:xxxx:xxxx:xxxx:xxxx/128
PrivateKey = 8Pnlu1nDpyVY20xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
DNS = 172.16.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::0/0
Endpoint = 185.102.219.26:2049
PersistentKeepalive = 25
PublicKey = mS3/WpXjnMAMmXjSpd4nFzx9HSE3ubv2WyjpyH2REgs=

My issue is that DNS fails on any client connected to this router once I activate IVPN wireguard connection with this error:

;; communications error to 127.0.0.53#53: timed out

This issue is not reproducible with wireguard connection to my home router although its configuration looks very similar.

Can you please advise how to troubleshoot this issue?

THX

I suggest you upgrade first to 23.05.3
21.02 is EOL

If you still experience problems after upgrading then please connect to your OpenWRT device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:

Remember to redact keys, passwords, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
cat /etc/config/dhcp
cat /etc/config/firewall
ip route show
ip route show table all
ip rule show
wg show
1 Like

There's no general issue with the router, and there's no general issue using router's wireguard client.
The issue is related to DNS only.

Here's some of the requested output:

# ubus call system board
{
	"kernel": "5.4.211",
	"hostname": "GL-MT3000",
	"system": "ARMv8 Processor rev 4",
	"model": "GL.iNet GL-MT3000",
	"board_name": "glinet,mt3000-snand",
	"release": {
		"distribution": "OpenWrt",
		"version": "21.02-SNAPSHOT",
		"revision": "r15812+885-46b6ee7ffc",
		"target": "mediatek/mt7981",
		"description": "OpenWrt 21.02-SNAPSHOT r15812+885-46b6ee7ffc"
	}
}
# wg show
interface: wgclient
  public key: DiQd6oOtt3S8xRuxCqOcQnUBmVAOlgOqS/zWhyiwiF4=
  private key: (hidden)
  listening port: 45759
  fwmark: 0x8000

peer: mS3/WpXjnMAMmXjSpd4nFzx9HSE3xxxxxxxxxxxxxxxxxxxx
  endpoint: 185.102.xxx.xxx:2049
  allowed ips: 0.0.0.0/0, ::/0
  latest handshake: 19 seconds ago
  transfer: 4.11 KiB received, 4.38 KiB sent
  persistent keepalive: every 25 seconds

There's no option to upgrade to OpenWRT 23.05.3 because this will overwrite GL.iNet's customized webUI.

Router is using dnsmasq for DNS, and the relevant service is running and listening on port 53; I ommit IPv6 listening in the following output:

# netstat -tulpen | grep dnsmasq
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      11164/dnsmasq
tcp        0      0 172.16.10.1:53          0.0.0.0:*               LISTEN      11164/dnsmasq
tcp        0      0 192.168.88.221:53       0.0.0.0:*               LISTEN      11164/dnsmasq
tcp        0      0 172.21.161.193:53       0.0.0.0:*               LISTEN      11164/dnsmasq
udp        0      0 127.0.0.1:53            0.0.0.0:*                           11164/dnsmasq
udp        0      0 172.16.10.1:53          0.0.0.0:*                           11164/dnsmasq
udp        0      0 192.168.88.221:53       0.0.0.0:*                           11164/dnsmasq
udp        0      0 172.21.161.193:53       0.0.0.0:*                           11164/dnsmasq
udp        0      0 0.0.0.0:67              0.0.0.0:*                           11164/dnsmasq

The error message on the client

;; communications error to 127.0.0.53#53: timed out

is pointing to a service listening on port 53 but not responding.
The same error is reported on router:

root@GL-MT3000:~# nslookup google.com
;; connection timed out; no servers could be reached

So, what is wrong here with dnsmasq?

It appears you are using firmware that is not from the official OpenWrt project.

When using forks/offshoots/vendor-specific builds that are "based on OpenWrt", there may be many differences compared to the official versions (hosted by OpenWrt.org). Some of these customizations may fundamentally change the way that OpenWrt works. You might need help from people with specific/specialized knowledge about the firmware you are using, so it is possible that advice you get here may not be useful.

You may find that the best options are:

  1. Install an official version of OpenWrt, if your device is supported (see https://firmware-selector.openwrt.org).
  2. Ask for help from the maintainer(s) or user community of the specific firmware that you are using.
  3. Provide the source code for the firmware so that users on this forum can understand how your firmware works (OpenWrt forum users are volunteers, so somebody might look at the code if they have time and are interested in your issue).

If you believe that this specific issue is common to generic/official OpenWrt and/or the maintainers of your build have indicated as such, please feel free to clarify.

1 Like

As a general point, Wireguard does not differentiate DNS packets from any other traffic.

When you have two outgoing connections you need to make sure the routing is correct, i.e. (in the simple case of the default single routing table) you can't have two 0.0.0.0 routes.

Also in the simple case, dnsmasq should be targeting one upstream server, or two that are closely related (reachable by the same network) as a backup. The answer is almost never that you must need more 'option dns' settings in your config.

Look, all your statements are generally valid.
However, I'm facing a very specific issue that is related to a wireguard configuration provided by a commercial VPN provider.
If I use a different wireguard configuration of my home router there's no issue.

One could also point to the wireguard client configuration that fails. However I can use the same config on my laptop's wireguard client w/o issues.

This means troubleshooting should be possible w/o pointing to a customized OpenWRT firmware that is not 100% identical compared to official firmware.

Why does it? This isn't a support service for GL.Inet's software. We don't know all the changes they might have made or the interactions those changes may have with other components.

If you want support with GL.Inet's software then ask them. Otherwise install an official copy of OpenWRT and we can progress here

1 Like