DNS not returning query response using WireGuard

We have configured a GL.iNet GL-AR750S-Ext (Slate) device that uses OpenWRT and configure to use WireGuard for a VPN. The "Interface" is configured to use a private DNS server (see client config below). Invoking nslookup returns the following:

nslookup not-the-real-dns-name.com.
Server: console.gl-inet.com

*** No internal type for both IPv4 and IPv6 Addresses (A+AAAA) records available for not-the-real-dns-name.com.

Wireshark capture shows:

  1. DNS query packet from ->
  2. DNS response packet from ->

But it also shows the following, which I'm guessing is because the nslookup checks eth0 as well as wg0:

  1. WireGuard packet from ->
  2. DNS packet from ->
  3. DNS packet from ->
  4. WireGuard packet from ->

Invoking "nslookup not-the-real-dns-name.com." generates a similar packet capture and returns the expected IP address. This makes sense to me because the nslookup is an app performing the queries directly, though I don't understand why there are also packets using WireGuard.

Any ideas of where to look would be appreciated.

PrivateKey = ********************************************
Address =

PublicKey = rtsPkzDDKF*******************MjQ=
AllowedIPs =
EndPoint = wireguard-1.our-domain.com:51820

Is there a route to network on the remote end?

Thanks for your input.

I didn't examine the route tables because the Wireshark captures show the DNS response returning to the device behind the Slate/VPN device. It's just missing the DNS answer that was in the DNS response in the WireGuard packet.

Sorry about the mashed together image - I'm restricted to a single image as a newbie. It shows the DNS answer at in the WireGuard channel but not in the packet sent to the client.

The missing answer is most probably due to rebind protection.
For the rest of the questions there are not enough configurations to help investigation. However you are routing everything to the wireguard tunnel, so whatever address doesn't exist in the routing table will be sent over the tunnel.

Thanks trendy. I think I've figured out second question has to do with the packet showing up on the different interfaces.

Any suggestions where to look (like logs) to confirm the rebind protection? And if so, where can I whitelist (?) the cause/source?

Check in network/dhcp and dns settings if Rebind protection is enabled and disable it.

1 Like

That was it. Thank you for the assistance.