DNS not returning query response using WireGuard

Installing and Using OpenWrt Network and Wireless Configuration
1

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
Address: 192.168.8.1

*** 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 10.25.0.12 -> 10.24.64.50
  2. DNS response packet from 10.24.64.50 -> 10.25.0.12

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

  1. WireGuard packet from 65.64.123.123 -> 10.24.0.4
  2. DNS packet from 10.24.0.4 -> 10.24.64.50
  3. DNS packet from 10.24.64.50 -> 10.24.0.4
  4. WireGuard packet from 10.24.0.4 -> 65.64.123.123

Invoking "nslookup not-the-real-dns-name.com. 10.24.64.50" 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.

[Interface]
PrivateKey = ********************************************
Address = 10.25.0.12
DNS = 10.24.64.50

[Peer]
PublicKey = rtsPkzDDKF*******************MjQ=
AllowedIPs = 0.0.0.0/0
EndPoint = wireguard-1.our-domain.com:51820

2

Is there a route to 10.25.0.12 network on the remote end?

3

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.

Mashed
Mashed1221×1152 55.4 KB

4

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.

5

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?

6

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

1 Like
7

That was it. Thank you for the assistance.

8

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.

9

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