LAN interconnections fail when internet down

[edhaswell]

[Note: edited for clarity since first posting.]

My internet recently went out due to an ISP issue. During this state, I discovered that the devices on my LAN could not connect to each other.

I'm running Merlin 384.15 on an AC68U clone (RT-AC1900P). I have DNSFilter enabled with DoT, pointing at Quad9. It's a pretty vanilla setup except for using YazFi to isolate two separate guest networks, with a little custom section in iptables to allow the guest networks to access a printer.

I imagine this could be an iptables problem, but am far from an expert at this kind of issue and it could lie elsewhere. Has anyone experienced this and fixed it, or know what the issue might be?

Thanks.

 

[Maverickcdn]

IoT vlans, with a little custom section in iptables to allow the guest vlan to access a printer.

Iptables doesnt affect LAN traffic, and Merlin/Asus firmware doesnt natively support vlans..... so is it an ebtables script for your printer??

Are you running a robocfg script or something else for vlans?

 

[dosborne]

I'm running Merlin 384.15 on an AC68U clone (AC1900P).

Is that the one that isn't supported?

https://www.snbforums.com/threads/the-tm-ac1900-is-not-supported.48056/

 

[edhaswell]

Sorry. Inadvertently used Tomato terminology. Ran Tomato for years up until a few months ago when I switched to Merlin. And it's been long enough since I set up the new router that I forgot some of the details. I obviously should have made better notes.

The "vlans" are actually guest networks configured through YazFi.

The printer-access bit is excerpted from iptables -L:

Chain ehVPA (1 references)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             2750dw6E6C190BC      tcp dpt:printer
ACCEPT     tcp  --  anywhere             2750dw6E6C190BC      tcp dpt:631
ACCEPT     tcp  --  anywhere             2750dw6E6C190BC      tcp dpt:laserjet
ACCEPT     all  --  2750dw6E6C190BC      anywhere

This is the entire ebtables -L output:

Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 4, policy: ACCEPT
-i wl0.1 -j DROP
-o wl0.1 -j DROP
-i wl0.2 -j DROP
-o wl0.2 -j DROP

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

But none of the stuff I care about is on either of the guest networks, so likely irrelevant. PCs, phones, Chromecast, etc are all on the main wireless networks.

 

[edhaswell]

Is that the one that isn't supported?

https://www.snbforums.com/threads/the-tm-ac1900-is-not-supported.48056/

No, it is the RT-AC1900, which IS supported. I should have been more specific.

 

[CaptainSTX]

Is that the one that isn't supported?

No the AC1900P is an AC68 with a faster processor that was sold originally by BestBuy. It is fully supported by Merlin.

It is not the T-Mobil private label router.

 

[Maverickcdn]

Does power cycling the router resolve the issue? Was it only during the WAN down state you noticed the issue? or did it persist after the WAN came back up?

Anything in the system logs that points to an issue?

 

[edhaswell]

Does power cycling the router resolve the issue? Was it only during the WAN down state you noticed the issue? or did it persist after the WAN came back up?

Anything in the system logs that points to an issue?

Test: yanked line to modem. Everything was fine until I bounced the router, after which LAN interconnections would not work (even by direct IP address), though individual devices were connected to the router and could hit the router's web interface. Once the WAN reconnected, everything worked again.

Regarding the system log, there was of course various unhappiness on view, but without good internet research ability at the time nothing leapt out at me as the obvious source of the problem in a fixable way. Now of course nothing but my own ignorance is in the way. From the log since reboot sans WAN (seems a little too long to include in full here), some excerpts:

May  4 22:05:05 WAN_Connection: Fail to connect with some issues.
May  4 22:05:06 avahi-daemon[283]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
...
May  4 22:05:38 YazFi: Firewall restarted - sleeping 60s before running YazFi
May  4 22:05:41 nat: apply redirect rules error! [many of these]
...
May  4 22:06:16 syslog: WLCEVENTD wlceventd_proc_event(401): eth2: Disassoc E8:DE:27:12:CB:FF, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
May  4 22:06:16 syslog: WLCEVENTD wlceventd_proc_event(386): eth2: Deauth_ind E8:DE:27:12:CB:FF, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
May  4 22:06:16 syslog: WLCEVENTD wlceventd_proc_event(386): eth2: Deauth_ind E8:DE:27:12:CB:FF, status: 0, reason: Class 3 frame received from nonassociated station (7)
...
May  4 22:06:38 YazFi: YazFi v3.2.2 starting up
...
May  4 22:06:41 YazFi: wl0.1 (SSID: ELAN-G) - sending all interface internet traffic over WAN interface [interesting but irrelevant since I don't care about the guest devices]

I tried looking up the avahi NSS/mDNS issue, but what I saw wasn't very revealing.

 

[Maverickcdn]

...
May  4 22:05:38 YazFi: Firewall restarted - sleeping 60s before running YazFi
May  4 22:05:41 nat: apply redirect rules error! [many of these]
...
May  4 22:06:41 YazFi: wl0.1 (SSID: ELAN-G) - sending all interface internet traffic over WAN interface [interesting but irrelevant since I don't care about the guest devices]

Amateur armchair guess is its an issue with your Yazfi installation/config. When YazFi restarted it borked the NAT rules and ended up just redirecting everything to the WAN interface instead of the Bridge.

When you flashed 384.15 did you reload an old config or install/configure everything fresh?? Best would be to read through the YazFi thread or just go ahead and purge/reinstall Yazfi as a starting point.