What's new

Local src--> local dest DNS Requests sent to upstream DNS with VPN Client

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

djmcfar

Occasional Visitor
This thread is for @RMerlin

On my RT-AC86U running Merlin 386.7_2, I run the VPN client in exclusive DNS mode because it is necessary to use all of our streaming services.
In the VPN Director I have rules to select WAN/VPN for the home computers in our network. Local nslookup queries are successful on the computers that are set for WAN, and fail on computers set for VPN tunnel. This behavior is consistant on Linux and Windows machines. For computers set to use the router's client VPN (packet sniffing with tcpdump-->pcap file and viewing on Wireshark) the local-src to local-dest DNS requests are being passed to upstream VPN servers, which is guaranteed to fail. The upstream responds correctly having recognized a private network request, with...

Screenshot from 2022-11-08 15-11-39.png

I suppose that this could be classified as a bug, because passing a private network DNS request to an upstream DNS server will fail every time, and there is no need to enter the tunnel for local requests. Would it be possible to implement a fix for this behavior ? Thanks in advance.
 
I forgot to add the steps to reproduce....

(1) setup an instance of VPN client, using exclusive DNS mode
(2) setup local node-1 to use the tunnel and node-2 to use the WAN
(3) from node-1 type "nslookup <private address>" where <private address> is the IP address of a device on the local network (query fails)
(4) repeat step 3 using node-2 (query succeeds)
(5) using VPN Director, switch node-1 to use the WAN, and node-2 to use the tunnel
(6) repeat steps 1 though 4 (now node-1 query succeeds and node-2 query fails).
 
I notice that all other local to local traffic or ARP is filtered from entering the tunnel, perhaps a local DNS request filter could be added also?
 
Local nslookup queries are successful on the computers that are set for WAN, and fail on computers set for VPN tunnel
This is expected, and simply a technical limitation of Exclusive mode - the firewall has no way of knowing if the request should be sent to the local dnsmasq or to the remote DNS. So, all DNS queries are sent to the remote server.
 
This is expected, and simply a technical limitation of Exclusive mode - the firewall has no way of knowing if the request should be sent to the local dnsmasq or to the remote DNS. So, all DNS queries are sent to the remote server.
So you are saying that when VPN exclusive mode is active, DNS filtering is not possible for WAN routing, meaning that there is no opportunity for the firmware to inspect the source address and DNS request address (or name) before it is passed onto the WAN interface ? If that is the case, the ability to use local hostnames within a private network was not taken into consideration with the VPN client running (a design flaw). The router handles it properly without VPN in the picture. I understand the need for DNS leak prevention, but it should have been implemented in a fashion that doesn't break local DNS queries.

From an old school embedded programming perspective, this is a simple problem to fix (I've been an embedded programmer for a very long time). This is disappointing to hear.
 
So you are saying that when VPN exclusive mode is active, DNS filtering is not possible for WAN routing, meaning that there is no opportunity for the firmware to inspect the source address and DNS request address (or name) before it is passed onto the WAN interface ?
No. Exclusive mode is based on the same technique as DNS filtering. The firewall intercepts all traffic sent to port 53, and redirects it to port 53 of your VPN provider. What I'm saying is that the firewall has no way of examining the content of the query to tell what's the domain of the requested query to determine whether to forward it or not.

I understand the need for DNS leak prevention, but it should have been implemented in a fashion that doesn't break local DNS queries.
As I said, it's a technical limitation. You either tell the firewall to intercept and redirect all DNS traffic (which is exclusive mode), or you don't (which is any of the other DNS modes).
From an old school embedded programming perspective, this is a simple problem to fix (I've been an embedded programmer for a very long time).
That has nothing to do with embedded programming, that has to do with understanding how iptables and DNS queries work.

If the fix is that easy, then please share it...
 
If the fix is that easy, then please share it...

Found a fix for the local reverse DNS over Exclusive mode VPN failure which preserves the Exclusive mode DNS leak prevention, by inserting the following rule at the head of the DNSVPNx chain(s). It checks if the DNS request is sourced locally, then checks for the reverse-arpa notation that would be present for queries on the private network. If it's a match, VPN is bypassed (in my case, .2.168.192.in-addr.arpa).

iptables -t nat -I DNSVPNx 1 -s 192.168.2.0/24 -m string --hex-string "|01|2|03|168|03|192|07|in-addr|04|arpa" --algo bm -j RETURN

The router is capable of adding this rule dynamically for any private network. I was only interested in a fix for the reverse lookups (I'm polishing up the name resolution of the ARP portion of an old network tool I wrote), but the router could also fix local forward lookups when it has the DHCP host names of the devices. I can view the streaming services that required Exclusive mode, and passed all of the online DNS leak tests at the sites I use.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top