[Release] Asuswrt-Merlin 384.6 is now available

[john9527]

When I say add, I am referring to that same thing, I do not know what @RMerlin was thinking.

I think he was thinking about an alert when selecting the option....I think that would be too obtrusive as well.

 

[ColinTaylor]

I have enable DNS Rebind protection.

The first command you entered didn't return 192.168.1.27 so it looks like it's working. Maybe the logging level for dnsmasq is different in Merlin's firmware compared to John's.

 

[chris.at]

Already planned. However be aware that disabling strict will nullify a good portion of the added security provided by DNSSEC, as someone hijacking a domain usually secured by dnssec would then bypass it simply by using a non-signed zone...

I ran into another problem with strict dnssec enabled on 384.6 - dual wan failover to usb enforced new dns servers (no option to set them static like on primary wan) and with dnssec enabled all requests stalled because the dns servers used by the lte provider don't support dnssec. So, maybe it would be useful to move the dnssec option from lan to wan setup page and bind it to primary wan? Otherwise I'd have to disable dnssec strict to use wan failover.

Regards,
Chris

 

[AntonK]

I read

As do I!

 

[RMerlin]

I ran into another problem with strict dnssec enabled on 384.6 - dual wan failover to usb enforced new dns servers (no option to set them static like on primary wan) and with dnssec enabled all requests stalled because the dns servers used by the lte provider don't support dnssec. So, maybe it would be useful to move the dnssec option from lan to wan setup page and bind it to primary wan? Otherwise I'd have to disable dnssec strict to use wan failover.

dnsmasq isn't configurable per WAN interface, it runs on your LAN - there's only one set of global setting for the whole router. I can't just move it to the WAN interface and have it behave differently based on which WAN is in use, the settings aren't instanced.

If one of your providers doesn't properly support dnssec, then you will need to either use static nameservers that do on this provider, or disable dnssec.

 

[RMerlin]

I added it to the popup help for dnssec...

That'd be fine, but I'd still expect most users to fail to even realize that you can get contextual help on many settings.

 

[Makaveli]

That'd be fine, but I'd still expect most users to fail to even realize that you can get contextual help on many settings.

Either there or just adding it to the changelog should be enough for most I would think.

I have enable DNS Rebind protection.

Mine is also the same log was clear and ns lookup is the same as yours.

 

[Treadler]

Already planned. However be aware that disabling strict will nullify a good portion of the added security provided by DNSSEC, as someone hijacking a domain usually secured by dnssec would then bypass it simply by using a non-signed zone...

If strict mode generates issues, then those issues should be resolved in the domain themselves, as pointed out by John. And it's actually a good thing if these issues are now visible, so people are aware about them, and can actually take steps toward fixing them.



Dunno if Simon decided not to do so for privacy reasons, but to me it looks like a no-brainer - without that critical information, it's impossible to tell what is going on, and that log message is mostly useless. That's something I will most likely port, and might see if Simon would be open in also merging that upstream.



DNSSEC is a rather complicated beast. Not all TLDs support every "official" ciphers for instance, so sometimes an issue might simply be a domain using a cipher type not supported by its TLD (or even its registrar).

I've always been using my ISP's DNS here, and never got a single complain in my system log.

Quad9 bullet proof here.
Unfortunately my ISP doesn’t do dnssec.

 

[skeal]

@HowIFix Try pasting the following into the command prompt of the PC you're doing the test from.

nslookup a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network

If it returns an address of 192.168.1.27 then rebind protection isn't working.

I get these results when running the above command from my Ubuntu pc:

Non-authoritative answer:
** server can't find a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network: SERVFAIL

Is this the expected output if things are working or....?

 

[ColinTaylor]

I get these results when running the above command from my Ubuntu pc:

Non-authoritative answer:
** server can't find a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network: SERVFAIL

Is this the expected output if things are working or....?

Yes. If you try the same command again but with <space>8.8.8.8 on the end, so you're querying google's DNS servers directly, it should return 192.168.1.27.

C:\Users\Colin>nslookup a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network 8.8.8.8
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
Name:    a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network
Address:  192.168.1.27

 

[HowIFix]

@RMerlin why in these 2 protocols PPTP or OpenVPN the traffic is reversed, you can see it in Bandwidth Monitor or in a Speed Test, but L2TP traffic is not reversed and I was wondering if you can see the code of them 3 and identify why only L2TP works well and fix the traffic in OpenVPN.

This can also help you find the problem: (QOS + VPN Client fix traffic reversed via custom rules)

Custom Rules for when Router is acting as a VPN Client
These custom rules fix tunneled traffic from being zero-rated (whitelisted) or have traffic in the wrong section (reversed) when using QOS.

Download:
iptables -D POSTROUTING -t mangle -o br0 -d 192.168.2.100/32 -j MARK --set-xmark 0x80000000/0xC0000000  &> /dev/null
iptables -A POSTROUTING -t mangle -o br0 -d 192.168.2.100/32 -j MARK --set-xmark 0x80000000/0xC0000000

"Incoming/download" traffic is being whitelisted/reversed on the download interface since Asus is marking "download" traffic with an "upload" mark.
The rule above switches the "upload" mark back into a "download" mark.
Since the original mark is preserved, download traffic will remain correctly identified by traffic type.

192.168.2.100/32 should be changed to match the iprange of your tunneled devices​

Upload:
iptables -D OUTPUT -t mangle -o $wan ! -s 192.168.2.1 -p udp --dport 25000 -j MARK --set-mark ${Downloads_mark_up} &> /dev/null
iptables -A OUTPUT -t mangle -o $wan ! -s 192.168.2.1 -p udp --dport 25000 -j MARK --set-mark ${Downloads_mark_up}

The upload mark assigned to upload traffic is completely lost after entering the VPN tunnel.
As a result, we have to lump ALL upload vpn traffic into a fixed user defined category.

192.168.2.1 should be changed to the IP of your router

-p udp --dport 25000 should be changed to the protocol and port of your VPN host/provider.​

Enjoy!

 

[RMerlin]

@RMerlin why in these 2 protocols PPTP or OpenVPN the traffic is reversed,

It's been known for years, and I have no idea why that's the case.

 

[skeal]

Yes. If you try the same command again but with <space>8.8.8.8 on the end, so you're querying google's DNS servers directly, it should return 192.168.1.27.

nslookup a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network 8.8.8.8
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
Name:    a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network
Address:  192.168.1.27

Hi @ColinTaylor I ran the above command and still get the same results:

~$ nslookup a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network 8.8.8.8
Server:        8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
** server can't find a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network: SERVFAIL

Is something wrong here? Thank you in advance. You are a wealth of knowledge sir!

 

[ColinTaylor]

Is something wrong here?

Do you have any kind of DNS redirection setup, like DNSFilter? You could try a different server, like 1.1.1.1 or 9.9.9.9.

 

[skeal]

Do you have any kind of DNS redirection setup, like DNSFilter? You could try a different server, like 1.1.1.1 or 9.9.9.9.

I don't have a dns filter. I am using dnscrypt, set to use DoH and CloudFlare as my anycast server. I have dnssec enabled on the dhcp page along with rebind protection. My Ubuntu PC is a basic install. I tried the above command with 1.1.1.1 at the end and it still gave the same fail error. Thanks Colin!!

 

[HowIFix]

It's been known for years, and I have no idea why that's the case.

I already knew it, but I was hoping that you with the experience already acquired, could find the cause of that problem and fix.

Can you compare the iptables of both, because for me it is not an error of Adaptive QoS, I think the error is in the OpenVPN iptables and only in L2TP are well configured or maybe you find the problem when comparing them.

 

[ColinTaylor]

I don't have a dns filter. I am using dnscrypt, set to use DoH and CloudFlare as my anycast server. I have dnssec enabled on the dhcp page along with rebind protection. My Ubuntu PC is a basic install. I tried the above command with 1.1.1.1 at the end and it still gave the same fail error. Thanks Colin!!

I don't know why it isn't working for you. I just tried it over a mobile network and it works for me. I do wonder whether those URLs are dynamically generated and are restricted in some sort of way.

Try issuing the command again from your router's command prompt. Here's another one you could try:

nslookup a.34.192.228.43.1time.192.168.1.188.forever.58e5cab6-0848-47c6-a74e-800359ad68fe.rebind.network 8.8.8.8

 

[skeal]

I don't know why it isn't working for you. I just tried it over a mobile network and it works for me. I do wonder whether those URLs are dynamically generated and are restricted in some sort of way.

Try issuing the command again from your router's command prompt. Here's another one you could try:

nslookup a.34.192.228.43.1time.192.168.1.188.forever.58e5cab6-0848-47c6-a74e-800359ad68fe.rebind.network 8.8.8.8

Thank you for your patience. I ran the command from ssh prompt on my router. It seems to be a success Colin. I ran this command:

nslookup a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network 8.8.8.8

And got these results:

nslookup a.34.192.228.43.1time.192
.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network 8.8.8.8
Server:    8.8.8.8
Address 1: 8.8.8.8 google-public-dns-a.google.com

Name:      a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network
Address 1: 192.168.1.27

This appears to be good to go then right...?

 

[ColinTaylor]

This appears to be good to go then right...?

Well as you can see it returned 192.168.1.27 which is the thing that rebind protection should stop. So if you issue the same command again but this time use your router's DNS it should not return that address:

# nslookup a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network 192.168.1.1

Server:    192.168.1.1
Address 1: 192.168.1.1 router.asus.com

nslookup: can't resolve 'a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network'

 

[skeal]

Well as you can see it returned 192.168.1.27 which is the thing that rebind protection should stop. So if you issue the same command again but this time use your router's DNS it should not return that address:

# nslookup a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network 192.168.1.1

Server:    192.168.1.1
Address 1: 192.168.1.1 router.asus.com

nslookup: can't resolve 'a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network'

Yes sir you are so right!! It worked just like your results but with my DNS. Thank you for setting me straight I am glad I know this is working now. Thanks Colin!