What's new

[Beta] Asuswrt-Merlin 380.60 Beta is now available

  • 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!

There's a few rare cases of WAN issues that I can't reproduce. Since 380.60 is going to be the first "no-downgrade-path" release, and WAN functionality is kinda critical, I decided to wait for newer code from Asus rather than release based on 3479.
 
Strict mode with policy based routing appears to work just as I would expect on my fork. If I dump the dnsmasq stats, I can see it starting at the top of the list and rolling down as necessary. And yes, it does show that occasionally I leak from the VPN servers to my first ISP server.

Code:
Jun 25 11:08:29 dnsmasq[2702]: time 5983
Jun 25 11:08:29 dnsmasq[2702]: cache size 1500, 0/1145 cache insertions re-used unexpired cache entries.
Jun 25 11:08:29 dnsmasq[2702]: queries forwarded 662, queries answered locally 35
Jun 25 11:08:29 dnsmasq[2702]: DNSSEC memory in use 2904, max 4840, allocated 149996
Jun 25 11:08:29 dnsmasq[2702]: server 209.222.18.222#53: queries sent 555, retried or failed 96
Jun 25 11:08:29 dnsmasq[2702]: server 209.222.18.218#53: queries sent 96, retried or failed 20
Jun 25 11:08:29 dnsmasq[2702]: server 68.105.28.11#53: queries sent 20, retried or failed 0
Jun 25 11:08:29 dnsmasq[2702]: server 68.105.29.11#53: queries sent 0, retried or failed 0
Jun 25 11:08:29 dnsmasq[2702]: server 68.105.28.12#53: queries sent 0, retried or failed 0
Jun 25 11:08:29 dnsmasq[2702]: server 2001:578:3f::30#53: queries sent 0, retried or failed 0
Jun 25 11:08:29 dnsmasq[2702]: server 2001:578:3f:1::30#53: queries sent 0, retried or failed 0

Yes, I am seeing the same problem with Policy rules (see my post). When using the rules regardless of configuration, I leak DNS servers. When I remove the policy rules, no leaks at all.

The only reason I am using policy rules is because if you click redirect internet traffic you get another box to kill the internet if the VPN is broken. By the way, when I used the policy rules my ISP sent me a warning message in my browser saying I had malware or bots controlling my internet. When I remove the redirect internet traffic box (and no policy rules)...no problems.

My only suggestion is can I have the internet kill switch as a separate box regardless if I redirect interent traffic (policy rules).
 
for 389.60 the no downgrade path is just on the GUI right? but we we can still downgrade/upgrade via CFE mode.

I'm sure you mean the 380.60 firmware level. ;)

With the final being based on an as yet unreleased firmware (from Asus), that assumption that a downgrade is possible at all (even via CFE mode) is looking very grim to me.
 
for 389.60 the no downgrade path is just on the GUI right? but we we can still downgrade/upgrade via CFE mode.

Yes, but that's assuming this won't change in the future, as Asus might very well also upgrade newer routers's bootloaders.
 
Yes, I am seeing the same problem with Policy rules (see my post). When using the rules regardless of configuration, I leak DNS servers. When I remove the policy rules, no leaks at all.

The only reason I am using policy rules is because if you click redirect internet traffic you get another box to kill the internet if the VPN is broken. By the way, when I used the policy rules my ISP sent me a warning message in my browser saying I had malware or bots controlling my internet. When I remove the redirect internet traffic box (and no policy rules)...no problems.

My only suggestion is can I have the internet kill switch as a separate box regardless if I redirect interent traffic (policy rules).

Accept DNS Configuration must be set to Exclusive if you want to ensure that VPN clients use only the VPN DNS servers.
 
Accept DNS Configuration must be set to Exclusive if you want to ensure that VPN clients use only the VPN DNS servers.

I did that and it did not make a difference. The only time I get a DNS leak is when I check the "redirect internet traffic" and then setup policy rules to have the VPN go to a particular IP address. When the redirect internet traffic is removed, I do not get a leak. (I used all ...strict, exclusive,none..)

Using DNSleak.com and other sites shows 5-6 different DNS versus the 1 when I do not use redirect internet traffic.

I really dont need the redirect internet traffic...the only reason I use it is that another box opens up so I can have the internet traffic killed when the VPN goes down. I rather see that box always available. Right now, to get around the issue I have the NAT turned off so when the VPN client goes down, the internet goes down without a NAT.

I have been changing configurations for days now..and I think these is some kind of issue with the policy rules. Note the DNS leak is not my ISP DNS. When I use a client app in windows or dont use the policy rules, my DNS reported is the same as my VPN IP address in all cases. Once I use policy rules, I get 5-6 different DNS addresses.

thanks
 
Once I use policy rules, I get 5-6 different DNS addresses.

That alone doesn't even make any sense, since most clients only use a maximum of two servers, and they generally only use the first one unless it has problems. Personally, I would doubt that the test itself is working properly (or, you are misunderstanding what it's meant to test).

I really dont need the redirect internet traffic...the only reason I use it is that another box opens up so I can have the internet traffic killed when the VPN goes down.

That's also a contradiction for me. You are worried about leaks, yet you say you don't want to redirect your Internet access and are only doing so because you want access to the option to block Internet access on the client going down.

I think you might be misunderstanding the way a VPN is intended to be used.

In any case, this is not an issue with this beta release.[/quote]
 
Last edited:
That alone doesn't even make any sense, since most clients only use a maximum of two servers, and they generally only use the first one unless it has problems. Personally, I would doubt that the test itself is working properly (or, you are misunderstanding what it's meant to test).
It's legit... For IPv4, dnsmasq will send the client a single (or multiple, but won't deal with that) IP address for DNS via IPv4 that is only a dnsmasq forwarder. However, dnsmasq itself will have a list of multiple DNS Servers that it uses to resolve. So, resolving an IP address make send queries to multiple servers. Add in IPv6, and it can be a long list..

If dnsmasq is itself using forwarders (forwarding to other forwarders) the list can become quite long.

As for how it's using more than one: Assume that the page includes a link for "this-doesn-exist.snbforums.com".. the client queries dnsmasq for an IP, which goes to fowarder #1. That forwards (eventually) to a real DNS server (actual DNS server), which then queries the root, and trickles up to the authoritative DNS server (perhaps called "dns.snbforums.com") which can log the attempt, and then send back a NEGATIVE response.... which causes the "actual DNS server" to send back the negative to the forwarder... and so the next forwarder in the list is tried... and so on... This causes all the DNS entries to be queried.
 
It's legit... For IPv4, dnsmasq will send the client a single (or multiple, but won't deal with that) IP address for DNS via IPv4 that is only a dnsmasq forwarder. However, dnsmasq itself will have a list of multiple DNS Servers that it uses to resolve.

I have yet to see an ISP that provided more than two DNS servers, and Asus's webui also only allows you to enter two. So at most, you should only be "seeing" two nameservers (or four if you have two more provided by the tunnel provider, and you aren't using Exclusive mode).

BTW, a negative response (NXDOMAIN) is considered a valid response, and shouldn't trigger another recursive lookup with a secondary DNS. Only a SERVFAIL should trigger querying from a secondary server.
 
I have yet to see an ISP that provided more than two DNS servers
I know that comcast returns FOUR... two for IPv4 and two for IPv6. DNSMasq will try all four if it doesn't get the answer it wants. (My term "negative" was a meant that the server is returning "failure" not "does not exist." Sorry for using a misleading term.)

Playing with this, I had a bit of fun: I configured dnsmasq on the router to return two IPv4 addresses: itself and my domain controller's DNS. I allowed the router to pick up DNS servers from comcast. Then I configured the domain controller to use "8.8.8.8" and "8.8.8.4" as DNS forwarders. Then, I checked one of the DNS leaks testers (https://www.dnsleaktest.com/, "extended test"), and I got back a list of SIX comcast DNS servers and 2 google servers... which indicates that the "DNS Servers" that comcast provides to customers might themselves be forwarders. (I disabled IPv6 for that test.)

Edit: Forgot to mention that on that last test, I also got back a 9th result which was my own DC's DNS... That happened because the windows DNS will fall back to using root servers if all forwarders fail.
 
I tried beta 2 on my rt-ac87u.
With the 380.59 firmware I had issues with the 5GHz wifi channel switching to DFS channels while I selected 48. This only happend when I enabled a 5GHz guest network.
After a flashing 380.60 beta 2 I did a powercycle and finally I got the channel I wanted :D
Did Asus do some wifi fixing?

Anyway, I'm very happy again, I haven't noticed any other issues. IPv6 is still working fine.
Thanks Merlin!:)
 
Running GRC Shields Up I got this report on the AC5300.

----------------------------------------------------------------------

GRC Port Authority Report created on UTC: 2016-07-09 at 01:08:51

Results from scan of ports: 0-1055

0 Ports Open
2 Ports Closed
1054 Ports Stealth
---------------------
1056 Ports Tested

NO PORTS were found to be OPEN.

Ports found to be CLOSED were: 135, 445

Other than what is listed above, all ports are STEALTH.

TruStealth: FAILED - NOT all tested ports were STEALTH,
- NO unsolicited packets were received,
- NO Ping reply (ICMP Echo) was received.

----------------------------------------------------------------------

Any idea why ports 135 (epmap) and 445 (microsoft-ds) are not reporting as stealth? This was not an issue with my AC3200 before I upgraded. Not sure if it was in 380.59 or not. I upgraded directly to this beta before testing.
 
I have a ac56r and this beta and all stealth as far as grc reports.I am just using as a router no other services .and it runs solid.



Running GRC Shields Up I got this report on the AC5300.

----------------------------------------------------------------------

GRC Port Authority Report created on UTC: 2016-07-09 at 01:08:51

Results from scan of ports: 0-1055

0 Ports Open
2 Ports Closed
1054 Ports Stealth
---------------------
1056 Ports Tested

NO PORTS were found to be OPEN.

Ports found to be CLOSED were: 135, 445

Other than what is listed above, all ports are STEALTH.

TruStealth: FAILED - NOT all tested ports were STEALTH,
- NO unsolicited packets were received,
- NO Ping reply (ICMP Echo) was received.

----------------------------------------------------------------------

Any idea why ports 135 (epmap) and 445 (microsoft-ds) are not reporting as stealth? This was not an issue with my AC3200 before I upgraded. Not sure if it was in 380.59 or not. I upgraded directly to this beta before testing.
 
I have yet to see an ISP that provided more than two DNS servers, and Asus's webui also only allows you to enter two. So at most, you should only be "seeing" two nameservers (or four if you have two more provided by the tunnel provider, and you aren't using Exclusive mode).

AC56u, 380.60Beta2
WAN DNS servers set to OpenDNS

OpenVPN+Policy Routing+Exclusive - ipleak.net shows only one DNS IP which matches VPN IP address
OpenVPN+Policy Routing+Strict - Completely breaks all WAN connectivity
OpenVPN+Policy Routing+Relaxed - ipleak.net shows six OpenDNS servers and VPN IP for DNS
OpenVPN+Policy Routing+Disabled - ipleak.net shows six OpenDNS servers.

With Google DNS setup under Wan DNS servers, ipleak.net will return a dozen or so Google DNS servers

Network Tools->Netstat->Netstat-nat will list only the two DNS servers set up under WAN, per client forced DNS and/or the VPN servers depending on VPN settings, but no forwarded servers like ipleak.net.

Aside from the strict setting breaking WAN connectivity, that is the behavior I would expect. I have also noticed that sometimes the browser seems to cache the DNS servers, so it might be necessary to restart the browser after changing settings and before going to ipleak.net.
 
Last edited by a moderator:
Running GRC Shields Up I got this report on the AC5300.

----------------------------------------------------------------------

GRC Port Authority Report created on UTC: 2016-07-09 at 01:08:51

Results from scan of ports: 0-1055

0 Ports Open
2 Ports Closed
1054 Ports Stealth
---------------------
1056 Ports Tested

NO PORTS were found to be OPEN.

Ports found to be CLOSED were: 135, 445

Other than what is listed above, all ports are STEALTH.

TruStealth: FAILED - NOT all tested ports were STEALTH,
- NO unsolicited packets were received,
- NO Ping reply (ICMP Echo) was received.

----------------------------------------------------------------------

Any idea why ports 135 (epmap) and 445 (microsoft-ds) are not reporting as stealth? This was not an issue with my AC3200 before I upgraded. Not sure if it was in 380.59 or not. I upgraded directly to this beta before testing.

Because many ISPs flat out reject connections to these ports, so that traffic never even reaches your router (or your modem). And as they are doing things "cleanly", they properly reject the connection rather than silently ignore it.

A closed port vs a stealth port is NOT a security issue. I wish GRC would stop spreading this FUD already...
 
Last edited:
I have also noticed that sometimes the browser seems to cache the DNS servers

It doesn't cache the servers, but it does cache resolved entries. So if you ran the test twice without closing and re-opening your browser between tests, whatever hostname the test tries to resolve to test your nameservers would still return the previous answers, skewing any test.

Resolved hostnames are cached at numerous levels these days: the router, the OS, and the application. Any proper test should ideally be done with a complete reboot of the computer. You might be able to get around with just a "ipconfig /flushdns", however there's no telling what other application might also be caching results (security suites for instance might potentially do so as part of some hijack protection mechanism).
 

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