Slate 7 Wireguard Client - Can't Resolve Remote LAN hosts using VPN DNS Settings

Hello,

Have a brand new Slate 7 running 4.8.1 and testing it out as a travel router to vpn back to a home Wireguard Server (PIVPN/Pi5) that supports a windows domain and internal windows DNS server.

Wireguard profile connects fine and from windows/iOS/Android clients is also able to resolve remote LAN host names with no issue using connection specific suffix included in conf file.

When using the same profile on the Slate 7, the tunnel comes up, but automatic DNS settings do not forward any requests to the remote LAN DNS servers. (ex: 192.168.8.100 client on SLATE 7, SLATE 7 lan eth = 192.168.8.1, remote DNS server (192.168.10.200))

NS lookup and ping both work fine on the client side of the tunnel on my PC, but without manually specifying the DNS server in the adapter settings, it wont resolve hosts on the server side lan. This leads me to believe there is an issue with the traffic between the Slate interfaces when the VPN tunnel comes up.

I can NOT ping or use NS lookup from the Slate 7 UI, or SSH to the remote DNS server even though these functions work from the computer client using the router/tunnel.

It seems that the router itself is unable to forward or receive the DNS requests over the tunnel when it is up.

I have also tried going back to 4.7.3 - this tunnel method allows ping from the router over the tunnel to the DNS server, but lookup still fails, it also stops the clients from being able to use the DNS even with a manual DNS configuration.

Also, unsure if the firmware and wireguard client supports connection specific suffixes like the software clients? (Seems like this may have been changed in the 4.8.x firmware as it reads the suffix now, but unsure if it works.)

Any suggestions ?

Update:
Only seem to have gotten this to work by editing dnsmasq.conf and adding “server=/*.domain.lan/192.168.10.200”

The automatic use of the wireguard DNS settings does not seem to work at all.

1 Like

Will ask R&D to check this.

Thanks for your feedback.

R&D has checked the cause and will fix this issue on future firmware versions.