WireGuard, Local Network access, and DNS

[rognorak 0]

Hello, 

I recently set up wireguard.  I then searched the forums, and found the post below to allow use of local network outside the tunnel: 
I noticed, on the connection with the default settings:

Allowed Ips: 0.0.0.0/0, ::/0
The only dns ipleak.net will detect is the AirVPN exit server -

But on the connection that allows local network suddenly 
ipleak.net picks up a bunch of google DNS servers - 

Id like some insight into why this is happening - also note I did not change the DNS settings, only the allowed IPS - 

How can I limit the DNS to the airvpn exit server and still allow local network access - 

Thanks 

















 

[Stalinium 44]

Quote

https://www.man7.org/linux/man-pages/man8/wg.8.html
AllowedIPs — a comma-separated list of IP (v4 or v6)
              addresses with CIDR masks from which incoming traffic for
              this peer is allowed and to which outgoing traffic for
              this peer is directed. The catch-all 0.0.0.0/0 may be
              specified for matching all IPv4 addresses, and ::/0 may be
              specified for matching all IPv6 addresses. May be
              specified multiple times.

Explanation: this is a list of IPs to which the Wireguard connection will be used. 0.0.0.0/0 already includes every possible IPv4, so your LAN IPs are gonna be redirected through AirVPN regardless. I don't think this changes how DNS works in any way thus ipleak should be in the same situation as before.
Technically you could allow LAN IPs through real network by excluding them in the allowed IPs.

Starting with:
- IPv4 spans from 1.0.0.0 to 254.255.255.255
- Local ranges are https://en.wikipedia.org/wiki/Reserved_IP_addresses
- It is usually enough if we only exclude 192.168.0.0/16 from the mask, not touching other (rare) private IP ranges

Lets assemble an AllowedIPs list that will include everything except our LAN.

# we are zooming in, allowing smaller networks at every step until we precisely exclude 192.168...
0.0.0.0/1 # 0.x.x.x to 127.255.255.255
128.0.0.0/2 # 128.0.0.1 - 191.255.255.254
192.0.0.0/9 # 192.0.0.1 - 192.127.255.254
192.128.0.0/11 # 192.128.0.1 - 192.159.255.254
192.160.0.0/13 # 192.160.0.1 - 192.167.255.254

# 192.168.0.0/16 does not make it into allowed list to NOT route it through WG

# This is its sister network
192.169.0.0/16 # 192.169.0.1 - 192.169.255.254

# From now on we're creating as large networks as possible again
192.170.0.0/15 # 192.170.0.1 - 192.171.255.254
192.172.0.0/14 # 192.172.0.1 - 192.175.255.254
192.176.0.0/12 # 192.176.0.1 - 192.191.255.254
192.192.0.0/10 # 192.192.0.1 - 192.255.255.254
193.0.0.0/8 # 193.0.0.1 - 193.255.255.254
194.0.0.0/7 # 194.0.0.1 - 195.255.255.254
196.0.0.0/6 # 196.0.0.1 - 199.255.255.254
200.0.0.0/5 # 200.0.0.1 - 207.255.255.254
208.0.0.0/4 # 208.0.0.1 - 223.255.255.254

# 224.0.0.0/4 is reserved as multicast
# Further addresses also reserved, we are done

You should be aware of implications of this routing though. The more precise a route is (higher /123 number, defining a smaller network) the higher priority it takes. This is important to know when you are going to have other routes and overrides in "route -4 print" on Windows.

A saner alternative is to add a single "192.168.0.0/24 route via my router" AFTER establishing a wireguard connection. wg-quick on Linux allows to do this, technically you could do this through another script on Windows or save a persistent route using the "route" command.

PS: I hope the above works as expected. I used a so called subnet calculator. Please provide a link here when reposting this solution.
PPS: For IPv6 just use link-local addresses with interface specifier.

[rognorak 0]

Hi, Thanks for the detailed reply

In re:

Quote

13 hours ago, Stalinium said:

I don't think this changes how DNS works in any way thus ipleak should be in the same situation as before.

That is exactly what I thought too... but it doesnt seem to be the case at all -

So I restored the original configuration (Ip addresses) , and then added a route ( temporary just to play with it ) and It didnt work - 
I then tried playing around with "block untunneled traffic" and disabled it - and the route allows local traffic, BUT the google dns servers have reappeared - 

This has something to do with how windows resolves DNS - once you allow any access at all outside the tunnel, windows seems to fall back based on adapter metric as described here:
`https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd197552(v=ws.10)?redirectedfrom=MSDN`

as an experiment, while connected to wireguard, I changed my lan adapter DNS setting to `127.0.0.1 ` and the only dns I see is airvpn - of course I cant leave it that way, and im not yet sure what to do about it - I may need a connection script to knock out the local adapter dns when connected or something - I will play around with it later today. 





  Edited ... by rognorak

[Stalinium 44]

In one of the updates Windows 10 introduced sort of a broadcast-type DNS lookups, that is it sends the query to all DNS servers it knows of. I remember this is configurable via Group Policies. Maybe that's what you are seeing?

[rognorak 0]

Hi @Stalinium - I did look in that ( https://answers.microsoft.com/en-us/windows/forum/all/how-to-force-windows-10-to-use-dns/5b80e376-fa6a-4c6e-b59d-5eb5ec65c26d ) but it doesnt seem to solve the problem - it seems more to be the metric on the adapters and the Windows failover process.  

I think If I want this ill need to do it with a script and remove the local adapter dns when I connect - I can prob do it with powershell, ill report back when I get around to it

Thanks for your help

[rognorak 0]

For anyone interested, enabling the following settings in the group policy editor did it for me 

Turn off smart multi-homed name resolution 
and
Turn Off multicast name resolution

[rognorak 0]

I take that back, it improved the problem, but eventually, dns still hits google, it just took many more dns tests on ipleak

[eStolkYw 13]

Your AllowedIPs field is wrong. You're sending your local traffic through the VPN connection. You need to use this tool to generate your AllowedIPs field. In AllowedIPs field enter 0.0.0.0/0, ::/0. In DisallowedIPs field enter your subnet block 192.168.... etc. It will generate the AllowedIPs field to run your lan outside of the VPN connection. You can also use this tool to help you determine which IP block to use for your subnet address.