How DNS could bypass VPN?

Software SW help
, ,
1

I’m currently sending traffic from LAN mainly through WireGuard VPN interface to VPN peer provider having it configured as Allowed IPs: 0.0.0.0/0

There’s no firewall ‘kill switch’ because as I’m utilizing PRB had to not set it up that way otherwise it’s not possible for certain devices on LAN to bypass VPN.

Doing it because don’t need to route IPTV for example through VPN, seems excessive to me.

As setting up this it raise my awareness what else should not delegate on VPN provider. And since it’s possible to have encrypted DNS therefore not necessary anymore having the VPN resolving for my connection, so choose to do it more locally.

Therefore on the WG VPN interface did check ‘Use default gateway’ (so expecting the Omnia/Kresd is now fully responsible for DNS queries, caching them) and erase entry in custom DNS servers having here in before the ones delivered to me in VPN config.

Rebooted Omnia and looking in LuCI on Status - Overview can see for both network interfaces 1) DHCP, WAN ethernet, having DNS 1/2: 192.168.0.1, same as gateway and 2) WG VPN - no DNS config.

In reForis for DNS: ‘Use forwarding/Enable DNSSEC’ and one of available choices. Test is OK.

But after checking the DNS behavior as to be seen from the Internet here the public IP address is the one provided by VPN. The DNS servers are to be the ones I choose so that is OK.

It does working as 0.0.0.0/0 catching all traffic if the interface is up so by default that is as expected - VPN provider doesn’t resolving but the query is send through VPN.

Therefore expanded the PBR with one more entry for DNS and since it’s hosted on Omnia, should it be the gateway IP(?), set that up for 192.168.0.1:443 853 (ports in case I decided use custom DNS and it’s the DoH instead DoT).

After running check again, switching multiple DNS providers (also custom) the result is the very same, DNS IP’s are ok, but my IP is still the VPN one not my ISP one.

If curl from ssh session in Turris it’s the VPNs also, if from the devices with already established PBR rule for it it’s the ISPs IP.

logs from /var/log/resolver

 19 15:50:22 TO kresd[5276]: [system] warning: hard limit for number of file-descriptors is only 4096 but recommended value is 524288
 19 16:01:49 TO kresd[9185]: [system] warning: hard limit for number of file-descriptors is only 4096 but recommended value is 524288
 20 12:39:29 TO kresd[7324]: [system] warning: hard limit for number of file-descriptors is only 4096 but recommended value is 524288
 20 16:22:42 TO kresd[7324]: [taupd ] active refresh failed for . with rcode: 2
 20 22:57:22 TO kresd[7324]: [taupd ] active refresh failed for . with rcode: 2
 20 23:36:51 TO kresd[13619]: [system] warning: hard limit for number of file-descriptors is only 4096 but recommended value is 524288
 21 15:35:40 TO kresd[13619]: [taupd ] active refresh failed for . with rcode: 2

(Searching here for what does it means - the file descriptor should be OK, that is standard message after restart(?), probably as I changed DNS server. The rcode: 2 however have no idea, but that’s outside of the scope with this post.)

nslookup example.xyz from Omnia will return 127.0.0.1:53 since that’s for Kresd process resides in machine I suppose. As from LAN the machines respond 127.0.0.53#53 for nslookup, pointing to Omnia.

tcpdump should show me Omnia (192.168.0.1) > WAN or WireGuard connections.

So from ssh in Omnia:

tcpdump -ttti eth2 src 192.168.0.1 and port 443 or 853

This one print nothing, that’s the WAN so here I’m expecting to be what wg0 is returning.

tcpdump -ttti wg0 src 192.168.0.1 and port 443 or 853

The last one capturing returning quite a lot ‘dns10.quad9.net.853 > 172.27.123.XXX.58237’ as the page testing DNS doing even 100+ queries.

Having the rule in PBR doesn’t working for traffic from Omnia on those ports.

Where’s my mistake if someone could spot it?

Than you all.

2

I’m not sure if you even want to do this. Some CDNs will tailor their DNS answers, based on origin of the DNS queries coming to their authoritative servers. They’ll answer IP addresses that they think best for your location. If you’ll be communicating with the CDN through a VPN, you can get better results by also letting DNS queries travel the same way.

3

Thank you for pointing this out - you’re right.

Originally the ‘it raise my awareness’ is what is left from thought about how the sending DNS into VPN could change what is delivered for my devices accessing WAN effectively different from the perspective of CNDs.

But since the intro part of the introduction post is long enough did craft that out in order to shorten the part.

That is the reason also why so far I choose to use exit IP nearby the ISP/router location therefore mitigate the possibility in before it happens (also because it’s hard for me to debug it, to know it’s happening). And it’s working I think.

And because behavior is now as described and this could do the ‘tailoring’ you’re talking about - all DNS is done in VPN but for all traffic (in VPN or outside via PBR).

Should specify that more precisely avoiding confusion - as PBR allow selected LAN devices traffic to go into WAN directly, not in the VPN, but only after the DNS query, if needed, is performed via VPN - therefore I’m trying to find out how to avoid that.

Would like to have all DNS for all devices done by Turris(Kresd) from/with help of/ server selected by me and through WAN not VPN.

4

What you are trying to achieve I believe is called DNS view or split horizon DNS and its not easy to do with kresd

https://knot-resolver.readthedocs.io/en/stable/modules-view.html

Also see warning

5

Spend an hour reading that, it’s advanced really and I’m not willing to implement it yet as don’t understand this properly.

It may solve some of the problems which may occur if my exit IP is really much different from the router location (2 cache each per PBR/VPN hosts) but it does not - to my understanding - solve how to force the path for DNS query originating from Kresd outside of VPN interface.

“but trying to serve different data to different clients will result in unexpected behavior.” different data because of some RPZ filter for example

The root cause of potential troubles will be different response from DNS server contrary the actual location.

As far as my understanding of this option for Kresd is - it’s working with the response not the creation of the response itself as that is on the DNS server and that differs eventually because of the location of the VPN vs DNS server itself.

Query policies: block, rewrite, or alter inbound queries based on user-defined policies. It does not affect queries generated by the resolver itself

In “Example configuration” can see drop, pass, deny - but that is not about the local router interface choose at all.

Anyway nice to see that this exist at least, did read some stuff about RPZ and DNS history - time well spend.

6

Source IP address for DNS requests coming out of kresd is configurable:
https://knot-resolver.readthedocs.io/en/stable/daemon-bindings-net_client.html#net.outgoing_v4

1 Like