RT-AC88U for secondary routing encountered DNS and VPN problems

mkjxrhfg

New Around Here
After activating the VPN activation for the secondary Routing, you can see in the primary Routing that the DNS for the secondary Routing is not tunneled through the VPN,I don't know how to fix it?
 

Attachments

  • Secondary Routing VPN Configuration.png
    Secondary Routing VPN Configuration.png
    34.8 KB · Views: 76
  • Secondary Routing WAN Configuration.png
    Secondary Routing WAN Configuration.png
    95.8 KB · Views: 75
  • As seen in the primary route (secondary route version 386.3.2).png
    As seen in the primary route (secondary route version 386.3.2).png
    31.2 KB · Views: 69
  • As seen in the primary route (secondary route version 386.4).png
    As seen in the primary route (secondary route version 386.4).png
    42.2 KB · Views: 72

eibgrad

Part of the Furniture
You're probably right about 8.8.8.8 and 8.8.4.4 NOT being routed over the VPN, but you wouldn't know that from the netstat information. All it's showing is the destination IP and ports being used, but NOT which network interface is being used to route those DNS queries out to the internet. For that you'd need to use my DNS monitor utility.


What you're likely to find is that 8.8.8.8 and 8.8.4.4 are in fact being routed out the WAN/ISP. And that's because starting w/ 386.4, ASUS now statically binds the WAN's DNS server's to the WAN (!) (presumably to ensure the integrity of the periodic WAN check). But given you're using DoT (aka Stubby @ 127.0.1.1), those custom servers aren't even necessary. Had you left them blank, there'd be nothing for the router to bind to the WAN. All the router could do is use Stubby for name resolution, which is a local process. And Stubby itself is bound to the VPN because of having "Route Internet traffic through tunnel" set to Yes (all).

In fact, perhaps an even better solution is what I explain in the following link regarding binding the router itself to DNSMasq (an idea that originated from @SomeWhereOverTheRainBow).


One other point. Whether DoT needs to be routed over the VPN is an arguable point. Once DNS is encrypted, it doesn't really matter all that much which network interface is used. The only real (and limited) benefit of routing DoT over the VPN is so the ISP doesn't even know you're using DoT, and which servers, and perhaps in some extreme case, having the ISP block port 853. But for the most part, it just isn't necessary. In in your case, it just comes as a side-effect of having all your traffic routed over the VPN.
 

SomeWhereOverTheRainBow

Part of the Furniture
You're probably right about 8.8.8.8 and 8.8.4.4 NOT being routed over the VPN, but you wouldn't know that from the netstat information. All it's showing is the destination IP and ports being used, but NOT which network interface is being used to route those DNS queries out to the internet. For that you'd need to use my DNS monitor utility.


What you're likely to find is that 8.8.8.8 and 8.8.4.4 are in fact being routed out the WAN/ISP. And that's because starting w/ 386.4, ASUS now statically binds the WAN's DNS server's to the WAN (!) (presumably to ensure the integrity of the periodic WAN check). But given you're using DoT (aka Stubby @ 127.0.1.1), those custom servers aren't even necessary. Had you left them blank, there'd be nothing for the router to bind to the WAN. All the router could do is use Stubby for name resolution, which is a local process. And Stubby itself is bound to the VPN because of having "Route Internet traffic through tunnel" set to Yes (all).

In fact, perhaps an even better solution is what I explain in the following link regarding binding the router itself to DNSMasq (an idea that originated from @SomeWhereOverTheRainBow).


One other point. Whether DoT needs to be routed over the VPN is an arguable point. Once DNS is encrypted, it doesn't really matter all that much which network interface is used. The only real (and limited) benefit of routing DoT over the VPN is so the ISP doesn't even know you're using DoT, and which servers, and perhaps in some extreme case, having the ISP block port 853. But for the most part, it just isn't necessary. In in your case, it just comes as a side-effect of having all your traffic routed over the VPN.
If the user performs a trace route to say for example

www.google.com, and has their dns solution going through the tunnel, it should show hops associated with whatever the vpn provider uses.

The opposite is true when dealing with dns pointed to WAN. You will see servers associated with ISP in the hops.
 

Similar threads

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