386.14_2 Hacked? 'Unrecoverable' Guest network issue

[Tech9]

If you can live with the way it looks and the larger physical size - GT-AX6000. It's basically the same hardware as RT-AX86U Pro, but with better 4-stream 2.4GHz radio and additional 2.5GbE port. Also has 3006 "Pro" firmware available for it with the same features.

 

[Natty]

Thanks. GT-AX6000 is looking like a good choice at the moment. However, I note that ASUS downloads page for that model only has 3006 Asuswrt firmware. From this post https://www.snbforums.com/threads/gt-ax6000-aimesh-clients-getting-knocked-off.93102/post-936265 it looks like I won't be able to flash Asuswrt-Merlin, at least not until that gets onto the 3006 codebase. So if I'd bought an older one that shipped with 3004, Asuswrt-Merlin upgrade is supported, but if the new one is supplied with 3006, I won't be able to enjoy the security and stability of Asuswrt-Merlin just yet. Is that correct?

 

[bennor]

it looks like I won't be able to flash Asuswrt-Merlin, at least not until that gets onto the 3006 codebase.

There is already Asus-Merlin Alpha 3006.102.4 firmware for the GT-AX6000.

[ 3006.102_4 alpha Build(s) ] available build(s)

https://www.asuswrt-merlin.net/test-builds This Alpha builds gives no support as they are in early state. Report any findings so they can be fixed in next alpha/beta release. 2025-18-03 3006.102_4_alpha2 is out. 2025-25-03 3006.102_4_alpha2 is out-g774261a90a 3006.102.x (xx-xxx-xxxx) -...

www.snbforums.com

Pre-beta test builds

 

[st3v3n]

Thank you for your thoughts @bennor. Re-flashing and restoring a previous known good config & JFFS restored normal operation. I agree that h/w failure can cause Wi-Fi issues, but I think in my case this can be ruled out because replacing the 1s and 0s fixed it.


@st3v3n different issue resulting from change to ASUS privacy policy. There are many posts on that irritating feature, and there is a browser script blocking work-around given by @Yota that I found useful: https://www.snbforums.com/threads/a...ilable-for-ac-models.91060/page-9#post-928691 The present issue affects guest network clients.


Stock 3.0.0.4.386_51733 would be my next port of call if this happens again (which I'm expecting it will eventually).

It would be great to know if 386.14_2 already has the security improvements of 3.0.0.4.386_51733 (I suspect it does not), but I think if we asked @RMerlin he would probably say (as he has said before) that the info provided by ASUS is insufficient to answer this.

In this single case, the ISP was knocked offline in the latest round of cyber attacks, and when their network failed, both killswitches in our Merlin/Asus OPVN clients worked instantly. Nothing apparently got through, however what I took to be the 'stock' Asus agreement began popping up the instant I logged into the router and on every single tab in the interface, demanding 'OK' be clicked. I couldn't track anything in the log where it came from or if ticking the OK (that I had read, not accepted, any Asus agreement, so since couldn't block it, it was just so out of the ordinary I instantly pulled the router out of service for testing.

Except for comparison tests, I haven't run stock Asus FW for years, so I replaced the Rog GT-AC2900 running Merlin v386.14.2 with it's identical twin router, running v386.12. Thus far, running Trend Micro or not running Trend Micro, there has been no reappearance of the stock Asus 'read this (then check OK) notice. The interface can't be used unless you verficy you read that notice, but for every single tab change? Supposing, since I've never found any other instance of this suddenly occuring on any other Asus model previously, running either Stock Asus or Merlin's FW, if someone with Asus decided out of the blue, to find and stream of insert a stock Asus User Notice into a perferctly running Asus router, running a recent version of Asus of Merlin FW, it would be a one-shot, click OK that the user has read it, and not continuously interfere by repeating on each and every tab the user clicks in the interface, ergo; it seemed immediately suspicious as hades, so I leaned into calling it a hack.

Am slowly testing/working forward from Merlin v386.10, to v386. 12, to v386.14, etc, each time wiping/defaulting the router and reinstalling Merlin and all paramters and FW OPVN clients from scratch. It's time-consuming to perform offline, and I never restore any saved configs to a working router, as doing so tends to introduce the same problem, bug or hack. So far, all tests are A-OK.

Asus released new stock FW in March '25 for the RT-AC86 and it's dressed up '86 brother), Rog GT-AC2900, so will make time to look at on of those releases as time permits. I know these routers are declared EOL by Asus and Merlin as of Dec 2024, but any new release may trickle down, and if so, it should help. As of today no one has yet reported any hinkiness with thes particular new Asus FW builds, and none of the repetitive Asus 'read/click OK' notices . I know that it's definitely not funny and, it's not an April fool's joke. Beware and take care out there, Cheers, S.

 

[Tech9]

Is that correct?

No, you can still flash 3004 Asuswrt-Merlin in Recovery.

Am slowly testing/working forward from Merlin v386.10, to v386. 12, to v386.14

The privacy notice came with Asuswrt-Merlin 386.14 and it's not present in stock Asuswrt.

 

[Natty]

Buttons have been pushed to purchase GT-AX6000 on account of its 4-stream 2.4GHz and Asuswrt -Merlin support, and thanks to @Tech9 recommendation. I also checked a few reviews and it seems like a reasonable bet right now, given the urgency.

After re-flashing 386.14_2 and restoring a 'good' backup config a second time, RT-AC66U-B1 seemed to work ok, except when I tried changing the passwords for the guest networks. After changing this (tried more than once, including power-cycling), guest networks block WAN access for LG WebOS TV and Android devices, though PCs seem unaffected. This is similar (if not identical to) the random failure of the original guest network that had been running fine for months. Did LG, iOS and Android recently update to enforce using some newer more secure 'wireless stuff' that is not supported by the EOL 386 firmware ? (reaching here, but could there be rational alternative explanation to being griefed by hackers?)

Either way, RT-AC66U-B1 is scheduled for disposal. I'm still using one as AP with wired backhaul to the main router. The AP has worked flawlessly and will continue in that role until replaced by a low cost AX AP - suggestions also welcome!

 

[Natty]

.. similar (if not identical to) the random failure of the original guest network that had been running fine for months. Did LG, iOS and Android recently update to enforce using some newer more secure 'wireless stuff' that is not supported by the EOL 386 firmware ? (reaching here, but could there be rational alternative explanation to being griefed by hackers?)

Might it be an unexpected manifestation of this issue: https://www.snbforums.com/threads/r...when-access-intranet-is-set-to-disable.90551/ ?

 

[Natty]

The problematic guest networks are 2.4GHz network 1 (subnet 192.168.101..) and 5GHz network 1 (subnet 192.168.102..). Access Intranet is set to Disabled. From reading on this forum, the other guest networks 2 & 3 are on the same subnet as the LAN, though also set to Intranet Disabled. These GNs did not suffer connection issues, just the first GN in each band.

Which gets me thinking about DNS. Primary and secondary DNS are specified in LAN-DHCP settings (Quad9). DNS director is OFF. I assumed that Intranet Disabled guest networks (1) would obtain DNS from the router (Quad9) unless clients request a different DNS server via their own DNS settings. Is this correct? Or, would DNS queries from clients on GN1 be passed through to the evil ISP?

Although I'm resigned to router replacement, I still want to understand why it is messing me around, because the next one might end up the same if I'm misunderstanding how to set it up correctly. Is using DNS Director and selecting 'router' and 'Quad9' better than just specifying the Quad9 DNS addresses in the DHCP settings?

 

[Ripshod]

We always advise, as we were always advised, to not use the first guest network. Unless things have changed.....

 

[Natty]

We always advise, as we were always advised, to not use the first guest network. Unless things have changed.....

Does that apply to just Asuswrt-Merlin or does it also apply to stock Asuswrt?

If stable, secure firmware is a key objective, why aren't the first guest networks permanently disabled on Asuswrt-Merlin 386 firmware if they should not be used? Can the 'first guest network' words of wisdom be confirmed please?

Does this also apply to 3006, which introduces even more VLANs to the guest networks?

Having wireless guest networks that are isolated from the LAN and from each other is a very useful and desirable feature (if it works).

 

[RMerlin]

In 386/388, the first Guest Network does work fine, it's just that it behaves differently than the others because it uses a different subnet. This is done so they can work better when synchronized accross AiMesh nodes. As a lot of people expect guest clients to still be on the same subnet as the main network, that's why it's often suggested to not use it. It's not defective, it just behaves differently from other guest networks, and people aren't always aware of the difference.

With 3006, the behaviour is default for all guest networks - they will all use a different subnet, however there is a setting to disable that behaviour if someone wants a guest network that still shares the same subnet as the main network.

 

[Natty]

Thanks @RMerlin for clarification about the Guest Network subnets. I would like to understand how DNS settings affect the Guest Networks, e.g. DNS director OFF vs. ON, and if GN DNS is different between 386/388 and 3006. Could someone kindly explain?

Primary and secondary DNS are specified in LAN-DHCP settings (Quad9). DNS director is OFF. I assumed that Intranet Disabled guest networks (1) would obtain DNS from the router (Quad9) unless clients request a different DNS server via their own DNS settings. Is this correct? Or, would DNS queries from clients on GN1 be passed through to the evil ISP?

.. Is using DNS Director and selecting 'router' and 'Quad9' better than just specifying the Quad9 DNS addresses in the DHCP settings?

 

[st3v3n]

No, you can still flash 3004 Asuswrt-Merlin in Recovery.



The privacy notice came with Asuswrt-Merlin 386.14 and it's not present in stock Asuswrt.

Yep, I concur, they sure 'nuff snuck that notice in, however this particular 'privacy/upgrade notice' never previously appeared in any form, on v386.14 or v386.14.2. Both versions always ran ran perfectly without notices or interuption, and without the continuous barrage of Asus 'click OK' notices on every dang tab in the GUI, so I call it not only irritation but an obvious abberation. TrendMicro's agreement/notice has always been once and done, tame by comparison. The circumstances which caused this sudden barrage of the notices, began only one the day following the latest cyberattacks which took down our ISP, breaking through our node into/through all of our security and possibly into the router. If true, then the breach would have been measured in milliseconds as our VPN cutoff alone should never have permitted our router security to be breached, but, 'never say never' again. Unlikely as I had thought, the GT-AC2900 may have been corrupted. Our second identical backup GT-AC2900 is in service, running v386.14 with no sign of said Asus privacy notice. The newest GT-AC2900 is the one we pulled from the system. We'd gone back up to 386.13, but as of this morning after more questionable behavior, it's been wiped and rebuilt from scratch.

The day of the attack, I was logged into the 2900's GUI, monitoring both OPVN clients, traffic/routing/logs on multiple tabs and IPS, when the ISP's connectivity abruptly dropped to zero, both OPVN client's killswitches cut in and our modem lights went dark. I immediatly cut power running to that network from the UPS; we never know if or when connectivity will return and letting them stay up only to blink for hours is ruinous and a waste of power. Ours is a rural area without a cellular net or other broadband providers, and though StarLink monthly service is double the cost we have now (not counting the buyin), it's become amazingly popular the the penny pinchers in our remote area. When we can switch, I'm hopeful that bypassing StarLink routers wifi to ethernet will give our VPN quality we've never had here in the boonies and wihout constant interruptions we've had siince last fall. As long as we don't experience the Kesler syndrome, anything at twice the price will be an improvement.

Not a rant, as this seems to be reaching other areas. Our former excellent ISP provider of many years was quickly/quietly absorbed last fall by a conglomerate, with no notice to customers. Last week, I tracked down one of the former engineers I'd known. He confirmed the buyout was one that the original, very ethical owners couldn't refuse; they and most company employees retired overnight. As a result, it's been as if the new robber-baron owners ordered severence of technical support and tossed all of the customers and their service into a black hole. We'd had great physical and technical service for 15 years then suddenly, the new company servers began going offline every day, then, several times daily, then at times, up to 2 or 3 days in a row once or twice per month. Instead reaching national technical support in 6 minutes, now it's 3 hours before reaching a foreign-based 'chat' person, consisting of at-home workers, all of whom have trouble just trying to read/understand their on-screen scripts. Their grasp of our language is as terrible as our trying to understand theirs, as a result, customers have stopped calling. In over four decades of working in the tech trenches in most of the lower 48 states, I thought I'd seen the worst of Cable/ISP operations, this one gets that award. Thanks for the reply, take care and hang tough.

 

[Natty]

So I think @st3v3n you are saying the EULA popup that started in 386.14 is due to the router being hacked? In which case mine has been compromised since that started popping up multiple times last summer. I used @Yota's u-block origin rule to ignore it. My Guest Networks continued to work just fine for many months, until now.

Release - Asuswrt-Merlin 386.14 is now available for AC models

Asuswrt-Merlin 386.14 is now available for all supported AC models. The focus of this release is the merge of an updated GPL, possibly the last GPL merge for the 386 series before support is dropped at the end of 2024. 17-Nov-2024: 386.14_2 is now available. 386.14_2 (17-Nov-2024) -...

www.snbforums.com

Don't be surprised to see pop up notices upon first login with this firmware update. These are the same notices reported in other recent stock Asus firmware threads. You can accept or decline some of the notices.

PS: Text from the notices is attached in a text file in case anyone wants to read them before flashing the firmware.

I'd still like to understand the GN DNS question of post #32 to be sure my GN issue is not simply bad DNS configuration, if someone could please educate me on that?

 

[ColinTaylor]

I'd still like to understand the GN DNS question of post #32 to be sure my GN issue is not simply bad DNS configuration, if someone could please educate me on that?

Conspiracy theories about hacking aside, I've just tested the GN#1 DNS behaviour...

GN#1 will ignore any LAN/DNS server settings and instead give the clients the router's alias IP address 192.168.101.1 (for 2.4GHz). Which in turn means clients will ultimately use the DNS servers defined in the WAN DNS settings.

GN#2/3 will give the clients the DNS IP addresses defined under LAN - DHCP Server.

DNS Director does effect all Guest Networks in the normal way. So if DNS Director has Global Redirection set to "router" then clients will be silently redirected to the first LAN/DNS address if one is set. If a LAN/DNS address is not present it will force the use of the router as the DNS server (which in turn uses the WAN DNS servers).

 

[Natty]

Thanks @ColinTaylor. I'm keeping an open mind as to the cause of GN1 not connecting Android, iOS and LG WebOS TV to internet (until settings.cfg backup is restored). If WAN ISP DNS was used, the ISP was messing things up on the DNS side of things might be a plausible explanation. However, I can confirm that WAN DNS is assigned to Quad9, which rules out ISP meddling.

This reminded me that DNS rebind attack messages had appeared in the log about a week before my OP. I see there was another instance about 15min after I had posted this thread:

Mar 29 20:53:36 dnsmasq[792]: possible DNS-rebind attack detected: ag.dns-finder.com
Mar 29 20:53:37 dnsmasq[792]: possible DNS-rebind attack detected: ag.dns-finder.com

Not knowing what that means, I ignored it then forgot about it. Might it be relevant to this issue?

 

[ColinTaylor]

If WAN ISP DNS was used, the ISP was messing things up on the DNS side of things might be a plausible explanation. However, I can confirm that WAN DNS is assigned to Quad9, which rules out ISP meddling.

It's still possible for ISPs to monitor or hijack plain DNS requests regardless of what you've chosen (not that I'm suggesting they're doing this). The only way to protect against that is to use the DNS Privacy Protocol = DoT option (or DoH on the client).

 

[ZebMcKayhan]

This reminded me that DNS rebind attack messages had appeared in the log about a week before my OP. I see there was another instance about 15min after I had posted this thread:

[ag.dns-finder.com] resolves to 0.0.0.0 (atleast by Unbound and my isp dns) which is probably why it is blocked. This is probably a good idea:
https://www.oligo.security/blog/0-0-0-0-day-exploiting-localhost-apis-from-the-browser