Another way to avoid DNS leaks while using VPN for one network only

Installing and Using OpenWrt Network and Wireless Configuration
1

Due to certain streaming services blocking Mullvad's VPN servers, I needed a way to have two separate networks, one of which routes through the VPN and one that does not.

The closest posts that I found were No DNS on Guest Network when preventing DNS leaks which is pretty long and convoluted, Separate network is using LAN dns? where running two Dnsmasq instances is recommended as the solution, and How to use VPN policy-based routing to forward guest network to VPN? where policy-based routing is used for whatever reason.

Would the following setup be appropriate for preventing DNS leaks on the VPN-using network?

  1. Interfaces >> Advanced Settings > Use default gateway: uncheck
  2. Interfaces >> Advanced Settings > Use custom DNS servers: 10.64.0.1 (Mullvad's DNS, reachable via the tunnel)
  3. DNS weight: 1000 (don't think this is required)
  4. Interfaces >> Firewall Settings: Assign to a new firewall-zone
  5. Interfaces >> DHCP Server > Advanced Settings > DHCP-Options: 6,10.64.0.1 (Advertise the DNS via DHCP)

Then, in the Firewall - Zone Settings, make the new zone reject input, accept output, reject forward and allow forward to WGZONE (the zone of the WGINTERFACE, WireGuard tunnel).

Finally, under Traffic Rules, add a new rule to allow DHCP traffic from the new zone to the port 67, but do not allow DNS traffic.

With these settings, clients connected to the network get their IP addresses from the router's DHCP server, but can not reach the router's nor ISP's DNS server - all non-DHCP traffic is forced through the VPN.

Is this correct? Are any settings superfluous? This setup does pass the DNS leak test at mullvad.net/check as well as the dnsleaktest.com extended test. This seems to me like a simpler, self-contained approach than modifying the system-wide DHCP and DNS settings to use DNS forwarding and/or running multiple instances of the resolvers.

2

For the pros, the corresponding uci lines:

  1. network.VPN_LAN.defaultroute='0'
  2. network.VPN_LAN.dns='10.64.0.1'
  3. network.VPN_LAN.dns_metric='1000'
  4. firewall.@zone[_1].network='VPN_LAN'
  5. dhcp.VPN_LAN.dhcp_option='6,10.64.0.1'

And the firewall:

firewall.@zone[-1]=zone
firewall.@zone[-1].name='VPN_LAN_ZONE'
firewall.@zone[-1].input='REJECT'
firewall.@zone[-1].output='ACCEPT'
firewall.@zone[-1].forward='REJECT'
firewall.@zone[-1].network='VPN_LAN'

firewall.@forwardings[-1]=forwardings
firewall.@forwardings[-1].src='VPN_LAN'
firewall.@forwardings[-1].dest='WGZONE'

firewall.@rule[-1]=rule
firewall.@rule[-1].name='Allow_VPN_LAN_ZONE_DHCP'
firewall.@rule[-1].src='VPN_LAN_ZONE'
firewall.@rule[-1].dest_port='53'
firewall.@rule[-1].target='ACCEPT'

WGINTERFACE and WGZONE are setup as described here: https://mullvad.net/en/help/running-wireguard-router/ - the first one is simply the Wireguard client interface and the second one is its firewall zone.

3

@vgaetera could I bother you as you seem to have a lot of relevant knowledge :innocent:

4

PBR is a perfect use case for this situation

1 Like
5

What about a simple redirection of port 53 of a specific range of ip addresses or interface to the DNS server of choice?

And set a route for that DNS server through tunnel (or WAN if desired)

6

From what I know about PBR, it's way overkill for simply routing the guest network via VPN - the people in the thread are installing extra packages to make it easier, and still describe the process as a "complicated thing" - vs. the zone-based approach described above. Besides, it's hard to compare when the thread was never solved.

7

This is about avoiding DNS leaks (DNS traffic going outside the tunnel), not about choosing nor forcing the clients to use a certain DNS server.

Since the firewall forwardings are going to be in place (as per the Mullvad tutorial) anyway, my changes (vrt. Mullvad's lan: rejecting input; vrt. the usual guest/isolated network setup: not allowing DNS input) should be sufficient to force all (non-DHCP) traffic, including DNS traffic, through the Wireguard tunnel, thus preventing DNS leakage, correct?

8

changed into

Until you convey exactly what you want, you will never get an answer to your liking :wink:

9

Snark aside, I could've been clearer. What I want - which has not changed, you're quoting my description of the related thread I linked, literally titled "How to use VPN policy-based routing to forward guest network to VPN" - are the answers to these questions:

"is this simpler-than-proposed-elsewhere configuration enough to block DNS leaks? could it have even less settings?"

I also restated the first question in my reply to egc:

10

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