WG DNS leak over VPN

Installing and Using OpenWrt
1

Hi all

I am experiencing a DNS leak on my wireguard configuration.

I have two OWRT routers - Location A and Location B. Location B has a WG interface that points to WG at Location A. Location B also has some custom traffic routing rules that directs certain devices on my network to use the Wireguard connection in table 100 to use Location A.

The internet on this interface does work but I recently ran a DNS leak test and can see that my current physical location is being leaked.

Location 'A' Settings:

Listen Port: 51820
IP Addresses: 10.10.9.1/32

Peers:
Allowed IPs: 192.168.10.1/24, 10.10.9.3/24

Location 'B' Settings:

Listen Port: 51820
Ip Addresses: 10.10.9.2/32

Peers:
Allowed IPs: 0.0.0.0/0

This setup has been working for about a year now without any real issues, however I'd like to fix the DNS leak so devices at Location B that are routed through the VPN get a DNS from Location A.

It's my understanding that I need to set Location B to use the wireguard interface of 10.10.9.1 as the DNS address, however I can't seem to get this working.

Any help is much appreciated.

2

Please post output of

ubus call system board
3 
{
	"kernel": "5.15.150",
	"hostname": "Home",
	"system": "ARMv8 Processor rev 4",
	"model": "Bananapi BPI-R3",
	"board_name": "bananapi,bpi-r3",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "23.05.3",
		"revision": "r23809-234f1a2efa",
		"target": "mediatek/filogic",
		"description": "OpenWrt 23.05.3 r23809-234f1a2efa"
	}
}
4

And how making DNS request is a leak?

5

The VPN is at the router level on both sides.

Location A is at our home many many miles away. The two routed devices at Location B are routed to location A via the wireguard VPN.

On these devices, if I run a DNS Leak test, I'm given DNS servers that are local to me and not the location of Location A.

I also have an OpenVPN connection to Location A. If I run a DNS Leak test via OpenVPN, I am shown DNS servers local to Location A. However, wireguard is much faster than OpenVPN and I'd like to get rid of OpenVPN all together.

6

For what it looks you have to go to Networj/DHCP and DNS and enable option "Ignore resolv file" than check that forwarder servers are other sites' DNS service.

7

Thank you.

I see the "ignore resolv file" option, but if you can, can you elaborate a little more on the second part of your description?

Do I need to specify DNS inside of the wireguard interfaces?

On my OpenVPN setup, the DNS is set to the router IP of location A. This doesn't seem to do anything when translating over to wireguard.

8

In forwarders list mention DNS servers characteristic to your other location.

9

So:

  • check "ignore resolv file"
  • add DNS to DNS Forwarding's list

Does DNS need to be specified in the wireguard interface? Sorry to be so specific, but if I enter something incorrectly I won't have access to the other location to fix.

10

You override internet connection DNS servers for LAN with what you configure in DNS/DHCP. You can just revert changes in an instant while still on your LAN.

11

Ok I think I'm following now.

If I do this, will my normal LAN traffic still use the ISP DNS server? I only want the devices using the wireguard interface to have the remote DNS pushed to them. Other network traffic can remain as-is.

I appreciate your patience with me.

12

Disclaimer I just woke up and did not have my morning coffee yet

When using DNS via the VPN it is easy to get a DNS leak.
This is caused by the way OpenWRT treats DNS servers.
Basically all DNS servers added to the interfaces are used and not only the DNS server you added to the WG interface.

What you need to stop a DNS leak is to exclusively use the DNS server you set in the WG interface. See for some background information:

To solve this there are scripts which exclusively use the DNS server you set on the WG interface when the tunnel is up and make sure that there is a route setup through the WG interface for that DNS server (needed if you use PBR).
I use this script:

For a proper setup if both sides are OpenWRT routers three things are important

The first is to make sure that the DNS server from the other side can actually process your queries.
DNSmasq has to listen on all interfaces so also on the WG interface, by default this is the case but if you changed that then you have to add the WG interface as listen interface.
The second is that DNSMasq of the other side has to answer non local request.
For this disable Local Service only (DNSMasq: -local-service):
Luci DNS-DHCP > Filter >Local service only : untick/disable,
or in /etc/config/dhcp:

config dnsmasq
	option localservice '0'

The third is that the client side is now using a DNS server with a local RFC1918 address.
DNSmasq has rebind protection which shield you from using local addresses as that can be used to spoof DNS so on the client side you have to disable Rebind Protection:
Luci DNS-DHCP > Filter > Rebind protection untick/disable
/etc/config/dhcp:

config dnsmasq
    option rebind_protection '0'

instead of disabling Rebind protection you can also whitelist the domain of the other side
Luci DNS-DHCP > Filter >Domain Whitelist "set name of domain of other side"
/etc/config/dhcp:

config dnsmasq
    list rebind_domain 'set name of domain of other side'
13

How do you distinguish 2 types of clients?

14

@egc - thank you for your thorough response! I will give this a go tomorrow as it's getting late here. Upon first read, your directions are towards the limit of my expertise, but I'll give it a try nonetheless! I think this will solve my issue though. I'm not using PBR, but rather the native routing tools within OpenWRT. The IP addresses of the devices using the tunnel are in table 100 (see response below). Are all of your directions for the client-side router (the one I have access to)?

@brada4 - the clients on my end that use the VPN have static IP addresses that are routed via table 100 (Network > Routing). The wireguard interface has the 'Override IPv4 routing table' field set to '100' (Wireguard Interface > Advanced Settings). Everything else else on my network is left as default. All works, just DNS leak on the routed IPs.

15

The fact that you mention the use of table 100 is new information, meaning you are using Policy Based Routing.

If you want to use Split DNS (the clients using the tunnel using the DNS via the tunnel and clients not using the tunnel should use the regular DNS) you have to use the PBR package which has this capability:

.

1 Like
16

Thank you @egc

I did originally start with PBR a year ago but had some issues, so I switched to Network > Routing which has worked. Is this not possible with the stock Routing tools?

I did go in and try to re-configure and was able to replicate the previous setup, but am falling flat with the split DNS part. The results are now the same as the previous method.

Service > Policy Routing > Advanced Configuration:

Add wg0 and lan to supported interfaces

Add New Policy:

Name: iPad test
Local Addresses: 10.0.1.81
Protocol: TCP UDP
Chain: Prerouting
Interface: wg0

Network > DHCP and DNS > Static Leases:

Hostname: iPad
MAC Address: xxxx
IPv4 Address: 10.0.1.81
Tag: Use-DNS-VPN

This seems to get the iPad back online over the VPN, but I'm failing with DNS. In the guide you sent I do not see any Split DNS options (such as what I configure on the server side and what I configure in PBR on my side). Any advice? Sorry, I'm a little new with this!

17

There are several ways to manually make a split DNS, you can use DNSMasq option 6 or redirect DNS via nftables, for some background see:

1 Like
18

This is exactly what I was looking for! Thank you.

Question though, when using DNSMasq option 6 it says to disable random MAC addresses. I just simply need to find the MAC address of the routed device and enter it in the DHCP config?

19

Correct, but your devices can have random mac addresses so that they can have different mac addresses, so you must disable that on that device if applicable

20

Fantastic. On the server router do I just enable a traffic rule allowing port 53 TCP/UDP, source zone wg0?