Use VPN Exclusive DNS and Local DNS

[macster2075]

Thanks very much for the info.
How do I enter those codes in the router?

Also,
To make sure I understand how it works…
So when I visit the bank, it would auto connect to OpenVPN 1 and when I go to any other site it will automatically switch over to OpenVPN 2 server?

 

[eibgrad]

Thanks very much for the info.
How do I enter those codes in the router?

Codes? You mean the routing policy rules? You add them using the VPN Director.

So when I visit the bank, it would auto connect to OpenVPN 1 and when I go to any other site it will automatically switch over to OpenVPN 2 server?

Both OpenVPN clients needs to be continually active/enabled. When and if a request is made to the bank's server(s) by any WLAN/LAN client, it will be routed via OpenVPN client #1. Any WLAN/LAN clients you have explicitly bound to OpenVPN client #2 will be routed through it as long as its NOT for the purposes of reaching the bank's server(s).

 

[macster2075]

<blank> 171.161.148.150 OVPN1
<blank> 171.159.228.150 OVPN1

I was referring to this. The IPs for the bank, where do they go?

 

[macster2075]

here?

 

[eibgrad]

I was referring to this. The IPs for the bank, where do they go?

here?
View attachment 40028

Yes. But the idea was to NOT qualify it w/ a local IP so that *any* WLAN/LAN client could be routed over the VPN for access to the bank. Unless limiting it to 192.168.1.230 is your preference.

 

[macster2075]

Something like this?

 

[eibgrad]

Something like this?

View attachment 40030

Yes. Now any WLAN/LAN device (including 192.168.1.230) will be routed over OVPN1 if it attempts to access the bank, while 192.168.1.230 will be routed over OVPN2 for all other purposes.

 

[macster2075]

Awesome.. thanks so much.. I will be trying it out after work today to make sure it's working as intended!

 

[iTyPsIDg]

Some of us have been having a back and forth discussion on this very issue over the past week or so. As you've discovered, Exclusive bypasses DNSMasq, so you lose access to all its features (local name resolution, caching, ad blocking, etc.). And Strict actually doesn't even work properly. For all intents and purposes, it's no better than Relaxed, meaning ALL your configured DNS servers, whether from the WAN, DHCP server, or pushed by the VPN provider are made accessible. Just a matter of luck which ones get chosen at any given time. That's why so many resort to Exclusive, despite its other limitations.

What you can do is specify Disabled for Accept DNS Configuration on the OpenVPN client. Then configure the WAN w/ your preferred public DNS servers (e.g., 1.1.1.1 and 1.0.0.1). Those will be copied down to DNSMasq for the benefit of the WLAN/LAN clients. Then bind those same servers to the VPN using policy rules.

Cloudflare (primary) <blank> 1.1.1.1 OVPN1
Cloudflare (backup) <blank> 1.0.0.1 OVPN1

Before 386.4, that was sufficient. But now in 386.4, ASUS in their infinite wisdom decided to create static routes to bind the WAN DNS servers to the WAN! And so now when those policy rules redirect DNS through the VPN's alternate routing table, that routing table *also* contains those same static routes, thus the servers are still bound to the WAN. To overcome it, you also need to add static routes to the OpenVPN client's custom config field to bind them to the tunnel.

route 1.1.1.1
route 1.0.0.1

These will have a lower metric than the static routes for the WAN, and so now all your DNS will finally be bound to the VPN. This will also bind the router itelf to those same DNS servers. Even for the purposes of the WAN connectivity check. IOW, you should have complete DNS stealthiness w/ this configuration. You can verify all that w/ my DNS monitoring utility.

Tutorial - How to monitor DNS traffic in real-time

The following script allows for real-time monitoring of DNS on the router for the purposes of knowing what DNS servers are in use, and which network interfaces are being used. https://pastebin.com/AGNF8cC8 Overview One of the most difficult aspects of the router for users is managing DNS. DNS...

www.snbforums.com

When I use this configuration, everything is fine until my router restarts. After a restart, it will not connect to the Internet and the Internet light stays red on the router. I'm not able to log into the router again, either. I'm not sure if this is happening to anyone else but figured I would add and also link to my post about it.

 

[eibgrad]

When I use this configuration, everything is fine until my router restarts. After a restart, it will not connect to the Internet and the Internet light stays red on the router. I'm not able to log into the router again, either. I'm not sure if this is happening to anyone else but figured I would add and also link to my post about it.

There is so much going on on that router of yours, w/ all those addons, I have no way of knowing whether anything described in this thread is to blame. When it comes to certain problems, the only viable option is to start fresh w/ a factory reset (you can make a backup so you can always return to the current state), and at least confirm the above changes work as expected. THEN slowly add back the addons. Because there's no obvious reason it shouldn't work.

 

[iTyPsIDg]

There is so much going on on that router of yours, w/ all those addons, I have no way of knowing whether anything described in this thread is to blame. When it comes to certain problems, the only viable option is to start fresh w/ a factory reset (you can make a backup so you can always return to the current state), and at least confirm the above changes work as expected. THEN slowly add back the addons. Because there's no obvious reason it shouldn't work.

I was able to narrow down that the moment I make the stated changes (i.e. add the routes to the VPN Custom Config and add the policy rules to VPN Director), a reboot will cause me to not be able to log into the router again until I factory reset it.

Since my only goal for preventing the DNS leaks is to allow me to stream, and I found that all I need to do is use Nord's Smart DNS for the WAN DNS servers to allow me to stream, it doesn't make sense for the slow process of determining if some addon conflicts with the DNS routing changes.

My goal is to ensure that if anyone else experiences the problem, they are aware that this change could be a contributing factor. If I have some time, I might try implementing nothing but this change on my spare AC86U to see what happens.

 

[iTyPsIDg]

I was able to narrow down that the moment I make the stated changes (i.e. add the routes to the VPN Custom Config and add the policy rules to VPN Director), a reboot will cause me to not be able to log into the router again until I factory reset it.

Since my only goal for preventing the DNS leaks is to allow me to stream, and I found that all I need to do is use Nord's Smart DNS for the WAN DNS servers to allow me to stream, it doesn't make sense for the slow process of determining if some addon conflicts with the DNS routing changes.

My goal is to ensure that if anyone else experiences the problem, they are aware that this change could be a contributing factor. If I have some time, I might try implementing nothing but this change on my spare AC86U to see what happens.

I had some time, so I tried the AC86U.

1. At my last AirBNB I had to use a static IP address for the WAN on the AC86U.
2. I left that as-is when I unplugged the router.
3. When I plugged the router in today, I had the same issue (minus the red light).
   1. I couldn't log into the router.
   2. I couldn't access the internet.
4. As a result, I performed a factory reset using the WPS button on boot.
5. The AC86U is still running 386.4.
6. I then only set up the following:
   1. VPN Client 1with the custom configuration to include 103.86.96.100 and 103.86.99.100 (Nord's DNS servers)
   2. A policy via VPN Director to route all LAN traffic (192.168.50.0/24) and the above-referenced IPs via OpenVPN Client 1.

Again, I don't get the red light like I do on the AX86U, but after a reboot I immediately lose all access to the router and the internet.

I don't believe this should happen, but it does happen. Personally, I don't see any reason DNS needs to work before the VPN. Maybe this happens because I have the Killswitch enabled, to prevent unknowing leaks. In any event, sadly DNS must work before the VPN.

 

[eibgrad]

Maybe this happens because I have the Killswitch enabled, to prevent unknowing leaks.

That seems very plausible, and seems to be verified by my own recent testing.

When the built-in kill switch is disabled, the fact those DNS servers are redirected to the OpenVPN client's routing table is irrelevant, since that table doesn't even exist as yet. Not until the OpenVPN client actually gets connected. It just falls through to the main routing table. But w/ the kill switch enabled, the router will pre-populate the OpenVPN client's routing table so it can insert a 'prohibit default' route and prevent leakage. And now you have no access to DNS either, since it's bound to the VPN like everything else being blocked.

This is yet another side-effect of the recent change by ASUS to statically bind the WAN's DNS servers to the WAN starting w/ 386.4 (something I warned would be problematic when I first learned about it from Merlin; I just didn't know where and when). With that change, it now became necessary to take the extraordinary measures I suggested to the OP. Prior to 386.4, you could simply have added static routes to the OpenVPN client's routing table, without the need for routing policy rules. IOW, the binding of the WAN's DNS servers to the VPN would only occur at the point the VPN was actually connected, and irrespective of the state of the kill switch.

Again, I just knew this static binding of the DNS servers on the WAN by ASUS would eventually lead to problems down the road. And now here we are.

I suppose another solution, if you insist on a kill switch, is to NOT use the built-in one, but one based on the firewall, like the one I created and in-use by a number of users who have other issues w/ the built-in version.

merlin-ovpn-client-killswitch.sh - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

Unlike the built-in kill switch, my script does NOT affect the router itself, but *only* the WLAN/LAN clients being routed through the router. IOW, the router itself is *never* a participant in the kill switch. Another one of those subtle differences between using the routing system vs. firewall to manage the kill switch.

 

[iTyPsIDg]

That seems very plausible, and seems to be verified by my own recent testing.

When the built-in kill switch is disabled, the fact those DNS servers are redirected to the OpenVPN client's routing table is irrelevant, since that table doesn't even exist as yet. Not until the OpenVPN client actually gets connected. It just falls through to the main routing table. But w/ the kill switch enabled, the router will pre-populate the OpenVPN client's routing table so it can insert a 'prohibit default' route and prevent leakage. And now you have no access to DNS either, since it's bound to the VPN like everything else being blocked.

This is yet another side-effect of the recent change by ASUS to statically bind the WAN's DNS servers to the WAN starting w/ 386.4 (something I warned would be problematic when I first learned about it from Merlin; I just didn't know where and when). With that change, it now became necessary to take the extraordinary measures I suggested to the OP. Prior to 386.4, you could simply have added static routes to the OpenVPN client's routing table, without the need for routing policy rules. IOW, the binding of the WAN's DNS servers to the VPN would only occur at the point the VPN was actually connected, and irrespective of the state of the kill switch.

Again, I just knew this static binding of the DNS servers on the WAN by ASUS would eventually lead to problems down the road. And now here we are.

I suppose another solution, if you insist on a kill switch, is to NOT use the built-in one, but one based on the firewall, like the one I created and in-use by a number of users who have other issues w/ the built-in version.

merlin-ovpn-client-killswitch.sh - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

Unlike the built-in kill switch, my script does NOT affect the router itself, but *only* the WLAN/LAN clients being routed through the router. IOW, the router itself is *never* a participant in the kill switch. Another one of those subtle differences between using the routing system vs. firewall to manage the kill switch.

I'll bookmark this in case my needs change in the future; for now, it seems my streaming needs are met without forcing the DNS through the VPN.