RC-AC66U - Problems with Dual WAN, suspected DNS

[gin]

I'm having a problem with Dual WAN behavior of the RT-AC66U router. There seems to be an intermittent problem with DNS queries from the clients (tested wireless) behind the router in some cases. It generally works, but fails from time to time.

ASUS RT-AC66U Firmware version 3.0.0.4.376.3754
Dual WAN in Failover mode with Failback
- WAN port (Static IP) - all data given by ISP1, also using Cloned MAC
- Second WAN port on LAN1 port (DHCP) - ISP2

After initially setting up the router out of the box I was offered and did an automatic firmware upgrade to the latest version, but I didn't reset - do I typically need to? I have setup Dual WAN directly and tested with pulling cables from the router and it generally works. Switching in both directions takes a couple of minutes though, please comment how fast should it happen? Watchdog function not activated. Just reloading in the client and after a couple of minutes it starts to work, but definitely not quick and transparent.

After all I stopped experimenting and settled on using the primary WAN port connection leaving the LAN1 port connected.

Then I figured out that DNS queries from clients occasionally fail. If trying to resolve the same address (e.g. www.dropbox.com) several times it eventually works for a minute and then fails again. Meanwhile the connection is stable (e.g. continuous ping), just the DNS resolution fails.

I have rebooted the router, but the DNS problem remains. I have noticed that 192.168.1.1 is given as DNS to my DHCP clients rather than the current ISP DNS address, so the DNS service in the router somehow fails. What kind is the DNS service in the router - passthrough or some kind of caching DNS server?

After turning off Dual WAN configuration, the primary ISP connection on WAN port now works stable without DNS issues.

Any ideas what may be wrong?

 

[texashoser]

You need to post the logs.

With that said, the 68U has known dual WAN failover bugs.

 

[gin]

I found the answers - all bugs

I found the answers and it's all about bugs I wonder how big is the ASUS software department and how much they care about this still expensive device to have such trivial bugs for many years in production. I'm gonna write with use cases style to describe all the problematic sequences and hope someone implement fixes.

Use case: Configure Dual WAN for the first time and then trigger failover
Goal: Switch the active connection to the second WAN port
Preconditions: DDNS enabled to update ASUSCOMM.COM
Brief: The user configures Dual WAN for Failover and second port WAN port to be LAN1. Right after that the WAN ports status are "Connected | Disconnected". The user plugs the second cable in the newly configured port. The user then pulls the cable from the first port.
Result: Dual WAN is never able to change the second WAN port to Connected, because a premature DDNS update to "ns1.asuscomm.com" with EMPTY IP is tried and rejected, and the failover sequence STOPS.
Workaround: Only reboot of the router breaks the sequence and solves this situation.

Use case: Failback on Dual WAN Failover configuration
Goal: Active connection switches to the first WAN port
Precondition: Connection is active on second WAN port. LAN DHCP Server is configured with DNS server field empty (implies sending 192.168.1.1 to clients and router internally handling DNS requests). First WAN port is configured Static IP. Second WAN port is LAN1 and configured Automatic DHCP.
Brief: User connects cable to the first WAN port. The failback sequence starts and switches the active connection to the first WAN port.
Result: Embedded DNS server internally remembers DNS entries from both WAN connections and fulfills requests on address 192.168.1.1 on random principle, sometimes successfully, sometimes returning error during DNS lookup due to inaccessible DNS servers remembered from Second WAN port (obviously restricted for use only by own ISP's clients).
Result: Embedded DNS server is poisoned with wrong data the first moment the second WAN port goes in "Standby" or "Connected" status or after reboot when both WAN ports become status "Connected | Standby". DNS servers remembered from both WAN ports are used on random principle assuming they are globally accessible.
Workaround: Override LAN DHCP Server to be 8.8.8.8. Thus the DHCP clients are able to avoid contacting the malfunctioning embedded DNS server and work properly. The obvious problem is this is not a good configuration because using a distant server. Embedded DNS server should respond only by asking currently active DNS for the currently active WAN port.

Use case: Override LAN DHCP Server to be 8.8.8.8
Goal: Send predefined DNS server to DHCP clients.
Brief: User sends predefined DNS server to DHCP clients to avoid using router's embedded DNS server.
Result: The DHCP clients receive both "8.8.8.8" AND "192.168.1.1". There is no way to avoid sending DNS "192.168.1.1" to DHCP clients. There is no way in UI to override second DNS entry for DHCP Clients. This problem is partially mitigated because TCP clients typically try all DNS entries if some of them fail.

 

[gin]

Slow switching of WAN Potts

Another problem with the above configuration is the slow switching of WAN ports. See what happens when I trigger a failover and a failback.

Slightly before 01:32:42 - disconnect second WAN cable. It takes more than a minute (around 80 seconds) to switch until 01:33:58. Notice how the NTP update goes crazy every 10 seconds. It never stops. Any chance this being the failback monitoring mechanism implemented via NTP update?

Slightly before 01:36:51 - plug in back the second WAN cable. Failback is much faster at around 10-15 seconds. NTP update calms down.

Feb  4 01:32:42 WAN(0) Connection: Ethernet link down.
Feb  4 01:32:42 stop_nat_rules: apply the redirect_rules!
Feb  4 01:33:37 rc_service: wanduck 692:notify_rc restart_wan_if 0
Feb  4 01:33:41 rc_service: wanduck 692:notify_rc restart_wan_line 1
Feb  4 01:33:41 start_nat_rules: apply the nat_rules(/tmp/nat_rules_vlan3_vlan3)!
Feb  4 01:33:41 pptpd[1149]: MGR: Config file not found!
Feb  4 01:33:41 miniupnpd[1115]: received signal 15, good-bye
Feb  4 01:33:41 miniupnpd[1181]: HTTP listening on port 55052
Feb  4 01:33:41 miniupnpd[1181]: Listening for NAT-PMP traffic on port 5351
Feb  4 01:33:41 ddns update: ez-ipupdate: starting...
Feb  4 01:33:52 ddns update: connected to ns1.asuscomm.com (103.10.4.108) on port 80.
Feb  4 01:33:52 ddns update: Asus update entry:: return: HTTP/1.1 200 OK^M Date: Tue, 03 Feb 2015 23:33:51 GMT^M Server: Apache/2.4.9 (Unix) PHP/5.5.14 OpenSSL/1.0.1h^M X-Powered-By: PHP/5.5.14^M Content-Length: 0^M Connection: close^M Content-Type: text/html^M ^M
Feb  4 01:33:52 ddns update: retval= 0, ddns_return_code (,200)
Feb  4 01:33:52 ddns update: asusddns_update: 0
Feb  4 01:33:52 ddns: ddns update ok
Feb  4 01:33:58 ntp: start NTP update
Feb  4 01:34:09 ntp: start NTP update
Feb  4 01:34:19 ntp: start NTP update
Feb  4 01:34:29 ntp: start NTP update
Feb  4 01:34:39 ntp: start NTP update
Feb  4 01:34:49 ntp: start NTP update
Feb  4 01:34:59 ntp: start NTP update
Feb  4 01:35:09 ntp: start NTP update
Feb  4 01:35:19 ntp: start NTP update
Feb  4 01:35:29 ntp: start NTP update
Feb  4 01:35:40 ntp: start NTP update
Feb  4 01:35:50 ntp: start NTP update
Feb  4 01:36:00 ntp: start NTP update
Feb  4 01:36:10 ntp: start NTP update
Feb  4 01:36:20 ntp: start NTP update
Feb  4 01:36:30 ntp: start NTP update
Feb  4 01:36:34 ntp: start NTP update
Feb  4 01:36:51 stop_nat_rules: apply the redirect_rules!
Feb  4 01:36:51 rc_service: wanduck 692:notify_rc restart_wan_line 0
Feb  4 01:36:51 start_nat_rules: apply the nat_rules(/tmp/nat_rules_vlan2_vlan2)!
Feb  4 01:36:51 pptpd[1230]: MGR: Config file not found!
Feb  4 01:36:51 miniupnpd[1181]: received signal 15, good-bye
Feb  4 01:36:51 miniupnpd[1262]: HTTP listening on port 40994
Feb  4 01:36:51 miniupnpd[1262]: Listening for NAT-PMP traffic on port 5351
Feb  4 01:36:51 ddns update: ez-ipupdate: starting...
Feb  4 01:36:52 ddns update: connected to ns1.asuscomm.com (103.10.4.108) on port 80.
Feb  4 01:36:52 ddns update: Asus update entry:: return: HTTP/1.1 200 OK^M Date: Tue, 03 Feb 2015 23:36:51 GMT^M Server: Apache/2.4.9 (Unix) PHP/5.5.14 OpenSSL/1.0.1h^M X-Powered-By: PHP/5.5.14^M Content-Length: 0^M Connection: close^M Content-Type: text/html^M ^M
Feb  4 01:36:52 ddns update: retval= 0, ddns_return_code (,200)
Feb  4 01:36:52 ddns update: asusddns_update: 0
Feb  4 01:36:52 ddns: ddns update ok
Feb  4 01:36:52 ntp: start NTP update
Feb  4 01:36:58 WAN(0) Connection: WAN was restored.
Feb  4 01:36:58 ntp: start NTP update

 

[texashoser]

Yes. Initial WAN failover is super slow - 3-5 minutes. Enabling watchdog introduces another bug...

 

[gin]

The perceived delay during failover for me was much longer until I enforced the 8.8.8.8 DNS server to avoid the malfunctioning embedded DNS server, unfortunately I didn't check the logs.

I feel cheated by ASUS for buying such a buggy device. Wondering if to return it to Amazon. Can you recommend some better alternative or I have to bear with this? Does Merlin have fixes to these bugs?

 

[texashoser]

Merlin's code doesn't address the dual WAN issues. Unfortunately, I haven't been able to find an equivalent linksys/cisco or netgear device that has dual WAN support.

For a while, ASUS was really good at responding to my support tickets, giving me updates, etc. Now they are silent on the issue.

 

[RMerlin]

Merlin's code doesn't address the dual WAN issues. Unfortunately, I haven't been able to find an equivalent linksys/cisco or netgear device that has dual WAN support.

For a while, ASUS was really good at responding to my support tickets, giving me updates, etc. Now they are silent on the issue.

Best dual wan product I've worked with so far is the Cisco RV042 (which went through a few HW revisions over the years, my two customers with one were early revisions). I only used it for failover, never tested it for load balancing.

Then, plug your wireless router of choice as an AP. This should give you the most reliable setup.

 

[texashoser]

Best dual wan product I've worked with so far is the Cisco RV042 (which went through a few HW revisions over the years, my two customers with one were early revisions). I only used it for failover, never tested it for load balancing.

Then, plug your wireless router of choice as an AP. This should give you the most reliable setup.

Thanks for the info. Just curious why Asus can't get their act together and fix these issues that have persisted for over a year. What's mind boggling is that, at least in my case, dual WAN works when watchdog is turned off (of course, with limited failover functionality). But with watchdog turned on - a SIMPLE function that monitors a remote host with a series of ICMP queries - suddenly the device sees DHCP errors coming from the primary WAN connection that magically weren't present before. What ICMP queries of a remote site have to do with DHCP is beyond me. And if I use a static IP on my primary WAN connection, suddenly PPPoE errors (when PPPoE isn't even configured) crop up when magically they weren't there before, either.

So, my assumption is that in my current configuration with watchdog disabled, unless the physical connection between the Asus router and my primary WAN modem goes down, failover won't happen - even if the primary WAN connection has no internet access.

 

[gin]

In my case Dual WAN bothers me as long as this was the first I tried to configure right out of the box to compare the 2 ISP cables coming into my house and quickly decide which one to leave. And it fails. Not that I critically need Dual WAN, but this reveals the mentality of the manufacturer. Can't wait to see what other surprises the product has for me.

I was asking for an alternative from this standpoint, if you can recommend a comparable higher quality product.

 

[RMerlin]

I was asking for an alternative from this standpoint, if you can recommend a comparable higher quality product.

I already answered that question a few posts above yours.

 

[gin]

Ok, if you mean that only the Dual WAN function of the AC66U is currently broken, I'm satisfied. Dual WAN started to bother me, but is not critical for me.

ASUS took my feedback to engineering, let's see what fixes they will produce.

 

[texashoser]

Ok, if you mean that only the Dual WAN function of the AC66U is currently broken, I'm satisfied. Dual WAN started to bother me, but is not critical for me.

ASUS took my feedback to engineering, let's see what fixes they will produce.

That's what they told me back in August... My last feedback to them was tell them the same problem was happening after upgrading to their latest firmware. Their response? "Have you upgraded to the latest firmware?"

They're just lame.