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:
*** No internal type for both IPv4 and IPv6 Addresses (A+AAAA) records available for not-the-real-dns-name.com.
Wireshark capture shows:
- DNS query packet from 10.25.0.12 -> 10.24.64.50
- 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:
- WireGuard packet from 184.108.40.206 -> 10.24.0.4
- DNS packet from 10.24.0.4 -> 10.24.64.50
- DNS packet from 10.24.64.50 -> 10.24.0.4
- WireGuard packet from 10.24.0.4 -> 220.127.116.11
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.
PrivateKey = ********************************************
Address = 10.25.0.12
DNS = 10.24.64.50
PublicKey = rtsPkzDDKF*******************MjQ=
AllowedIPs = 0.0.0.0/0
EndPoint = wireguard-1.our-domain.com:51820
Is there a route to 10.25.0.12 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.
That was it. Thank you for the assistance.
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.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.