[Beta] Asuswrt-Merlin 384.11 Beta is now available

[Zastoff]

Since I asked for more "Preset Servers" for DoT and the thrust of using DoT is security I thought I should bring up that not all upstream resolvers support TLS 1.3. I recommended CleanBrowsing but a test this morning with their secure resolvers failed when I had Stubby set to min TLS 1.3. I removed the min TLS Stubby setting and they worked .
So, if the resolver provider does not support TLS 1.3 should they be on the list?

Was using CleanBrowsing-Security(DoH) in DNSCrypt so when i read your post i did a test..i know it`s not DoT but quad9 and CleanBrowsing dont use TLS1.3 it seems

[doh-cleanbrowsing-security] TLS version: 303
[quad9-doh-ip4-filter-pri] TLS version: 303
[cloudflare] TLS version: 304

 

[MDM]

Interesting info about DNS Dot, and DNS provider performances:

"Besides its lack of protective and security measures, another con of Cloudflare is quite ironic—they’re dedicated to the privacy of users, but the DNS query data is shared with APNIC Labs in exchange for using its 1.1.1.1. And while Cloudflare claims that APNIC will not have access to IP addresses of users that make the DNS query data, we can’t seem to forget about Cloudbleed."
Quad9 is apparently a bit more "secure" about leaking info, but slower.

I presume most here know all this, but decided to share for those that do not...

 

[DonnyJohnny]

Was using CleanBrowsing-Security(DoH) in DNSCrypt so when i read your post i did a test..i know it`s not DoT but quad9 and CleanBrowsing dont use TLS1.3 it seems

[doh-cleanbrowsing-security] TLS version: 303
[quad9-doh-ip4-filter-pri] TLS version: 303
[cloudflare] TLS version: 304

Quad9 DOT is tls 1.3 ready as of Jan 2019
https://mobile.twitter.com/Quad9DNS/status/1083326937735544832
Stubby with tls min version set works with it.

 

[RMerlin]

So, if the resolver provider does not support TLS 1.3 should they be on the list?

I see no reason why not. TLS 1.2 is still considered secure enough, and TLS 1.3 in general is very new. That's why it's not being enforced.

 

[Xentrk]

Small Q, When I use DoT with VPN Client and select DNS Exclusive with a policy rule 192.168.1.0/24. I will get 1 DNS from my VPN provider (dns leaktest). When I use Exclusive and Redirect traffic set to ALL. I will get 1 DNS from my VPN provider plus a bunch DNS numbers from Cloudfare (dns Leaktest). In case of DNS (leaks) what do you recommend?

Be careful there @Sonyrolfy! Do you want Diversion to work when connected to the OpenVPN Client tunnel when using Policy Rules? If, so read on...

“Accept DNS Configuration” set to “Exclusive”

When combined with Policy Rules based routing, all clients configured to use the VPN will use the DNS servers provided by the VPN tunnel. LAN Clients configured to go through the WAN will use the DNS configured in the WAN Settings Screen.

The disadvantage of setting “Accept DNS configuration” to “Exclusive” when combined with Policy Rules is that DNSMASQ will be bypassed since the VPN tunnel will exclusively use the DNS of the VPN Provider. The popular Diversion ad blocker program, written for the Asuswrt-Merlin firmware, will not work since Diversion requires the features of DNSMASQ. Diversion will work over the VPN tunnel when “Accept DNS configuration” is set to “Exclusive” and Policy Rules are disabled by setting “Redirect Internet Traffic” to “All”.

There are two options available if you want the OpenVPN client to use DNSMASQ when using Policy Rules. This is done by setting “Accept DNS Configuration” to either “Strict” or “Disabled”.

“Accept DNS Configuration” set to “Strict”
If you set Accept DNS Configuration to “Strict”, you must then specify the DNS server for the VPN tunnel to use by adding the dhcp-option DNS command in the Custom Configuration section per the example below.

dhcp-option DNS 1.1.1.1

“Accept DNS Configuration” set to “Disabled”
My preferred recommendation is to set “Accept DNS Configuration” to “Disabled” and install Stubby DNS over TLS. Stubby DNS over TLS will encrypt DNS queries for all devices on the network. Or, with 380.11 Alpha/Beta, use the built in DoT functionality available in the firmware. Yes, a DNS Leak test will say you may be leaking DNS requests. But rest assured your DNS requests are going where you told them to - Cloudflare or another DoT DNS supported server, and not to your ISP.

Accept DNS Configuration Definitions
For reference, the definition of the Accept DNS Configuration field values are as follows:

• Disabled: DNS servers pushed by VPN provided DNS server are ignored.
• Relaxed: DNS servers pushed by VPN provided DNS server are prepended to the current list of DNS servers, of which any can be used.
• Strict: DNS servers pushed by the VPN provided DNS server are prepended to the current list of DNS servers, which are used in order. Existing DNS servers are only used if VPN provided ones don’t respond.
• Exclusive: Only the pushed VPN provided DNS servers are used.

See my blog site for more details.

 

[no_name]

I use your preferred recommendation of disabling my ExpressVPN DNS since DNS over TLS

For me it’s a happy compromise. Using Cloudflare means my policy rules remain strict, diversion works and the internet side of my TiVo v6 box works.

It takes a minute to change ExpressVPN DNS back to exclusive if I want to or I can use the app on my devices to bypass the routers configuration


Sent from my iPad using Tapatalk

 

[Swistheater]

Was using CleanBrowsing-Security(DoH) in DNSCrypt so when i read your post i did a test..i know it`s not DoT but quad9 and CleanBrowsing dont use TLS1.3 it seems

[doh-cleanbrowsing-security] TLS version: 303
[quad9-doh-ip4-filter-pri] TLS version: 303
[cloudflare] TLS version: 304

Was this test done while using dot or doh?

 

[EmeraldDeer]

I should be seeing DNSFILTER rules in addition to DNSFILTER_DOT, right?

I have even disabled DNSFILTER Global Router mode.

# iptables -S | egrep -i "53|dns"
-N DNSFILTER_DOT

And re-enabled.

# iptables -S | egrep -i "53|dns"
-N DNSFILTER_DOT
-A FORWARD -i br0 -p tcp -m tcp --dport 853 -j DNSFILTER_DOT
-A DNSFILTER_DOT ! -d 192.168.50.1/32 -j REJECT --reject-with icmp-port-unreachable
-A YazFiINPUT -i wl0.1 -p udp -m udp --dport 53 -j ACCEPT
-A YazFiINPUT -i wl0.1 -p tcp -m tcp --dport 53 -j ACCEPT

EDIT: Please disregard, "iptables -S" does not include "iptables -t nat -S"

# iptables -t nat -S | egrep -i "53|dns"
-N DNSFILTER
-N YazFiDNSFILTER
-A PREROUTING -s 192.168.50.0/24 -p udp -m udp --dport 53 -j DNSFILTER
-A PREROUTING -s 192.168.50.0/24 -p tcp -m tcp --dport 53 -j DNSFILTER
-A PREROUTING -p udp -m udp --dport 53 -j YazFiDNSFILTER
-A PREROUTING -p tcp -m tcp --dport 53 -j YazFiDNSFILTER
-A DNSFILTER -j DNAT --to-destination 192.168.50.1
-A YazFiDNSFILTER -i wl0.1 -j DNAT --to-destination 192.168.66.1

 

[Sonyrolfy]

Be careful there @Sonyrolfy! Do you want Diversion to work when connected to the OpenVPN Client tunnel when using Policy Rules? If, so read on...

“Accept DNS Configuration” set to “Exclusive”

When combined with Policy Rules based routing, all clients configured to use the VPN will use the DNS servers provided by the VPN tunnel. LAN Clients configured to go through the WAN will use the DNS configured in the WAN Settings Screen.

The disadvantage of setting “Accept DNS configuration” to “Exclusive” when combined with Policy Rules is that DNSMASQ will be bypassed since the VPN tunnel will exclusively use the DNS of the VPN Provider. The popular Diversion ad blocker program, written for the Asuswrt-Merlin firmware, will not work since Diversion requires the features of DNSMASQ. Diversion will work over the VPN tunnel when “Accept DNS configuration” is set to “Exclusive” and Policy Rules are disabled by setting “Redirect Internet Traffic” to “All”.

There are two options available if you want the OpenVPN client to use DNSMASQ when using Policy Rules. This is done by setting “Accept DNS Configuration” to either “Strict” or “Disabled”.

“Accept DNS Configuration” set to “Strict”
If you set Accept DNS Configuration to “Strict”, you must then specify the DNS server for the VPN tunnel to use by adding the dhcp-option DNS command in the Custom Configuration section per the example below.

dhcp-option DNS 1.1.1.1

“Accept DNS Configuration” set to “Disabled”
My preferred recommendation is to set “Accept DNS Configuration” to “Disabled” and install Stubby DNS over TLS. Stubby DNS over TLS will encrypt DNS queries for all devices on the network. Or, with 380.11 Alpha/Beta, use the built in DoT functionality available in the firmware. Yes, a DNS Leak test will say you may be leaking DNS requests. But rest assured your DNS requests are going where you told them to - Cloudflare or another DoT DNS supported server, and not to your ISP.

Accept DNS Configuration Definitions
For reference, the definition of the Accept DNS Configuration field values are as follows:

• Disabled: DNS servers pushed by VPN provided DNS server are ignored.
• Relaxed: DNS servers pushed by VPN provided DNS server are prepended to the current list of DNS servers, of which any can be used.
• Strict: DNS servers pushed by the VPN provided DNS server are prepended to the current list of DNS servers, which are used in order. Existing DNS servers are only used if VPN provided ones don’t respond.
• Exclusive: Only the pushed VPN provided DNS servers are used.

See my blog site for more details.

Hi Xentrk,

Thanks for he heads up, i do know these settings to get Diversion working. I just do it different.

Some Explanation.

I did set up 1 VPN client that specifically will use Exclusive for let’s say (mission critical) Devices.

Stubby on the router will get the VPN connection after clock is set by DoT. That’s great!

The 2nd VPN client is by setup where Diversion will kick in, totally leaving the VPN DNS out provided by my VPN provider. The DNS for this client is set to disabled. The devices for this particular VPN client is less critical, read: Phones, Tablets, TV’s etc. This will provide me the satisfaction to have Diversion work on these devices without any disturbance of annoying ad’s in Games/News/Free app’s. Etc Etc.

I did setup 3rd VPN client that’s will use a global approach of connections outside the country for less critical but needed for another reason.. The DNS setting for this particular client is set to exclusive, with no leaks of any DNS but my VPN. I could combine 1 and 3, but the downside of this is offcourse a higher latency and ping, so ended up making separate clients.

The beauty of Diversion is that it is greatly working against annoying ad’s for my less mission critical devices, where DNS 1.1.1.1 servers may have a local approach for speed. AMTM is very user friendly to get Diversion started out of the box or even without AMTM its very User friendly with just the copy of a line to get it on the USB stick and done.

In the beginning, I was trying DNS Filters, but then I couldn’t stir VPN ip’s to my desired destination.

In the end, it’s another approach but it gets the job done. Combined a great piece of Software!

Thanks Xentrk.

 

[jerry6]

384.11 BETA WORKING WELL SO FAR 28 hours , nothing strange in logs , just startup takes a while and have to log into network before vpn will work , never had that before , but not a big deal , used to log into vpn automaticly

 

[seth_space]

GPL merges: 384_5951 (RT-AX88U), 384_45713 (all other models)[
3.0.0.4.384.5951
Bug Fix
- Fixed Network Map related issues.

In the RT-AC3200 and this firmware it is NOT fixed!
Still the same problems. Network list very unstable and unreliable![/QUOTE]

 

[Sanna1967]

In the RT-AC3200 and this firmware it is NOT fixed!
Still the same problems. Network list very unstable and unreliable!

[/QUOTE]
Normal!
RT-AC3200 and RT-AC5300 still using 384_45149 binary blobs)
These 2 models still running under the old GPL that had this problem. Read the changelog correctly :

- UPDATED: RT-AX88U to 384_5951 GPL.
- UPDATED: Other models to 384_45713 GPL (RT-AC87U, RT-AC3200 and RT-AC5300 still using 384_45149 binary blobs)asus fault

 

[seth_space]

Thanks, i stopped reading probably when i saw"\GPL merges: 384_5951 (RT-AX88U), 384_45713 (all other models)

 

[Zastoff]

Was this test done while using dot or doh?

In Dnscrypt(DoH) with log level 1

 

[truglodite]

Maybe a minor bug?

Running 11b, dot, VPN server+client, and the usual scripts etc... ac86u

I noticed when I change settings on the wan page and DNS filter page, the webui isn't refreshing correctly. It gets stuck at 'applying settings', and I have to manually refresh to get it working again. The settings get applied and the webui continues to work, but it used to refresh itself a few seconds after changes. The other parts of the webui are working fine.

[Edit: disregard this post... the issue is not related to Merlin fw... it is a know bug with a script I'm using]

 

[jsbeddow]

Maybe a minor bug?

Running 11b, dot, VPN server+client, and the usual scripts etc... ac86u

I noticed when I change settings on the wan page and DNS filter page, the webui isn't refreshing correctly. It gets stuck at 'applying settings', and I have to manually refresh to get it working again. The settings get applied and the webui continues to work, but it used to refresh itself a few seconds after changes. The other parts of the webui are working fine.

If you are running any of Jack Yaz's recently added scripts, this is a known problem. You can either uninstall the script(s), or wait for updated versions.

 

[QuikSilver]

Maybe a minor bug?

Running 11b, dot, VPN server+client, and the usual scripts etc... ac86u

I noticed when I change settings on the wan page and DNS filter page, the webui isn't refreshing correctly. It gets stuck at 'applying settings', and I have to manually refresh to get it working again. The settings get applied and the webui continues to work, but it used to refresh itself a few seconds after changes. The other parts of the webui are working fine.

@Jack Yaz is working on it....post here instead.

https://www.snbforums.com/threads/p...ing-page-issue-while-using-his-scripts.56308/

 

[truglodite]

Ok I had a feeling... just came from the conmon thread and read across Jack's post mentioning he will soon be able to work on that. No need for me to poke him about it... he knows... and he is busy right now.

 

[skeal]

Anyone else here running this beta have a static IP from their Internet Service Provider?

 

[shark]

I have two questions:

First, when we enable DoT in wan, can or should we also enable "Enable DNSSEC support" ? I am asking this because before with stubby installed by ourselves, stubby would automatically set that option to no.

Second, is DoT in 384.11 also supporting IPv6?