Disabling "Access Intranet" on RT-AX86U guest network causes IoT devices on primary network to repeatedly disconnect

[mmseng]

Hi, I'm having an issue where some cheap Zengge (Magic Home) LED controllers are repeatedly losing connection to my primary wireless network whenever I disable "Access Intranet" on my guest network.

Previously I kept all IoT devices on my guest wifi network and disabled the bridging, as a standard isolation technique. This worked fine for years, including for these particular LED controllers. Recently I moved everything (including these controllers) to my primary LAN wireless network because I set up a Home Assistant server on the LAN. I'm not a huge fan of losing the isolation, but I'm coping with it for now, at least until I make a decision about whether to keep the HA server. While doing this I fully disabled my guest network to make things simpler. Everything worked as expected.

Afterward I turned my guest network back on and this causes these controllers to frequently lose their wifi connection. All 6 of them act exactly the same way. They usually stay connected for anywhere from 1 to 8 minutes, occasionally making it as long as 12 minutes, but rarely any longer.

It took me forever just to figure out that it was the guest network causing this. I tried tweaking dozens of settings in both the general wireless settings, professional settings, and guest network settings to no effect. Finally I figured out that enabling "Access Intranet" on the guest network solved the problem. But obviously I don't want to do this.

No other devices have this issue, so I recognize it could very well be a flaw with the specific LED controllers, however it doesn't make sense to me that the mere existence of a completely separate and unused network/SSID would cause this, and then only when unbridged. This is especially weird, because these devices existed on that unbridged guest network, coexisting with my primary wifi network for a long time, and only have issues when they are swapped to the primary wifi network. All of that being said, I'm vaguely aware that the primary and first guest wifi networks are somehow linked via the Asuswrt implementation, and also that the secondary and tertiary guest networks apparently work differently somehow. FWIW I have never tried using those additional guest networks.

I even went as far as packet capturing the communications from the LED controllers, in an attempt to see just WTF they are doing during these reset events. I got pretty close, but I think my available hardware and/or skills are not sufficient for making Wireshark decrypt their packets. (I can't manage to capture all 4 of the necessary EAPOL packets).

Can anyone think of a reason why a device connected to the main wifi network would work fine without the guest network on, fine with the guest network on and bridged, but NOT fine when the guest network is on and NOT bridged? Does the "connection reset every 1-10 minute" pattern ring any bells? I'm out of ideas and I've hit the limits of my knowledge and skills.

Thanks in advance for any insights or suggestions.

P.S. I googled extensively and this is perhaps the closest thread I've found with a similar sounding issue. Most of the suggestions there weren't helpful, although I admit I have not tried anything relating to IPv6 settings.

My environment:

• RT-AX86U running Asuswrt-Merlin 3004.388.4
• I normally have both the 2.4 and 5GHz radios on both the primary and guest network enabled (with sync'd settings), but I've tried all combinations of enabled radios, and used various wireless MAC filtering on the 4 SSIDs to force different combinations. The problematic devices only ever connect to 2.4GHz regardless, even though I think they technically support 5GHz (not sure on that).
• DHCP provided by the router. DNS provided by Pihole on the primary network.
• Single-family home with little to no external network interference, and literally all network devices are accounted for and have dedicated IP reservations on the LAN. There's usually a maximum of 20 devices that are connected at any one time.

 

[drinkingbird]

Hi, I'm having an issue where some cheap Zengge (Magic Home) LED controllers are repeatedly losing connection to my primary wireless network whenever I disable "Access Intranet" on my guest network.

Previously I kept all IoT devices on my guest wifi network and disabled the bridging, as a standard isolation technique. This worked fine for years, including for these particular LED controllers. Recently I moved everything (including these controllers) to my primary LAN wireless network because I set up a Home Assistant server on the LAN. I'm not a huge fan of losing the isolation, but I'm coping with it for now, at least until I make a decision about whether to keep the HA server. While doing this I fully disabled my guest network to make things simpler. Everything worked as expected.

Afterward I turned my guest network back on and this causes these controllers to frequently lose their wifi connection. All 6 of them act exactly the same way. The usually stay connected for anywhere from 1 to 8 minutes, occasionally making it as long as 12 minutes, but rarely any longer.

It took me forever just to figure out that it was the guest network causing this. I tried tweaking dozens of settings in both the general wireless settings, professional settings, and guest network settings to no effect. Finally I figured out that enabling "Access Intranet" on the guest network solved the problem. But obviously I don't want to do this.

No other devices have this issue, so I recognize it could very well be a flaw with the specific LED controllers, however it doesn't make sense to me that the mere existence of a completely separate and unused network/SSID would cause this, and then only when unbridged. This is especially weird, because these devices existed on that unbridged guest network, coexisting with my primary wifi network for a long time, and only have issues when they are swapped to the primary wifi network. All of that being said, I'm vaguely aware that the primary and first guest wifi networks are somehow linked via the Asuswrt implementation, and also that the secondary and tertiary guest networks apparently work differently somehow. FWIW I have never tried using those additional guest networks.

I even went as far as packet capturing the communications from the LED controllers, in an attempt to see just WTF they are doing during these reset events. I got pretty close, but I think my available hardware and/or skills are not sufficient for making Wireshark decrypt their packets. (I can't manage to capture all 4 of the necessary EAPOL packets).

Can anyone think of a reason why a device connected to the main wifi network would work fine without the guest network on, fine with the guest network on and bridged, but NOT fine when the guest network is on and NOT bridged? Does the "connection reset every 1-10 minute" pattern ring any bells? I'm out of ideas and I've hit the limits of my knowledge and skills.

Thanks in advance for any insights or suggestions.

P.S. I googled extensively and this is perhaps the closest thread I've found with a similar sounding issue. Most of the suggestions there weren't helpful, although I admit I have not tried anything relating to IPv6 settings.

My environment:

• RT-AX86U running Asuswrt-Merlin 3004.388.4
• I normally have both the 2.4 and 5GHz radios on both the primary and guest network enabled (with sync'd settings), but I've tried all combinations of enabled radios, and used various wireless MAC filtering on the 4 SSIDs to force different combinations. The problematic devices only ever connect to 2.4GHz regardless, even though I think they technically support 5GHz (not sure on that).
• DHCP provided by the router. DNS provided by Pihole on the primary network.
• Single-family home with little to no external network interference, and literally all network devices are accounted for and have dedicated IP reservations on the LAN. There's usually a maximum of 20 devices that are connected at any one time.

My first thought is those devices still remember the guest SSID and are swapping over to it (or attempting to). Are you using a totally new SSID for guest?

 

[mmseng]

My first thought is those devices still remember the guest SSID and are swapping over to it (or attempting to). Are you using a totally new SSID for guest?

I had briefly considered that perhaps they still had some sort of lingering settings related to the guest network, but I kind of dismissed it since the devices work fine on the primary network, plus in the course of troubleshooting I've "reset" them all several times, which for these devices means power cycling them 3 or 4 times in a row and re-pairing with their app. They don't have any interface by which I can see what network settings they're using, whether they might have additional network settings saved, or any mechanism by which network settings could be cleared, outside of doing the aforementioned "reset" procedure.

It also doesn't really make sense to me that the bridging mode of the guest network would have an effect on this.

But no, changing the guest network's SSID is not something I've tried yet, so I'll give it a shot. Thanks for the reply.

 

[bennor]

They don't have any interface by which I can see what network settings they're using, whether they might have additional network settings saved, or any mechanism by which network settings could be cleared, outside of doing the aforementioned "reset" procedure.

Check the IoT device's app to see if it is possibly saving the WiFi SSID and password info. Its possible the IoT online service (or local hub if it uses one) is saving the previous WiFi login information online. For example; Amazon's Echo devices does or did this, WiFi login information is/was saved to one's online Amazon account and one had to delete that online information else the device would attempt to connect to other WiFi networks first.

 

[mmseng]

Thanks. Unfortunately if that were actually the case then there's no way to fix it, and the stale wifi information is trapped in the device forever. As noted above, there is nowhere in the app that exposes this, factory resetting the device per the official instructions doesn't change the issue, and the company doesn't even have a website (outside of a few static knowledgebase pages); all account functionally is handled through the app.

 

[drinkingbird]

Thanks. Unfortunately if that were actually the case then there's no way to fix it, and the stale wifi information is trapped in the device forever. As noted above, there is nowhere in the app that exposes this, factory resetting the device per the official instructions doesn't change the issue, and the company doesn't even have a website (outside of a few static knowledgebase pages); all account functionally is handled through the app.

Try using a different SSID on the guest and see if it fixes it, then you at least know if that is part of the issue or not.

If they are on the guest and you enable guest isolation that would certainly explain why they stop working.

You can also look in the router status page to see which SSID they're connected to.

 

[mmseng]

Try using a different SSID on the guest and see if it fixes it, then you at least know if that is part of the issue or not.

If they are on the guest and you enable guest isolation that would certainly explain why they stop working.

You can also look in the router status page to see which SSID they're connected to.

I should mention is that I've primarily been monitoring the issue by watching the client list modal on the main "Network Map" page, using the "Interface" grouping. This list updates roughly every 3 seconds, and the devices never leave the primary SSID's 2.4GHz group. I also just checked the "System Log -> Wireless Log" page and I see the same behavior.

If they are attempting to connect to the guest SSID and failing then this might make sense. However the other thing I should have mentioned is that the guest SSID and password have both remained unchanged. So in theory, even if they are trying to auto connect to the guest SSID, they really should be succeeding.

I probably also failed to mention that DNS is functioning on the isolated guest network. So if they were successfully connecting to the guest SSID, they should not be dropping due to a lack of DNS. DNS is being successfully passed from even the isolated guest network to the pihole on the primary network, which is proven by forcing my phone onto the isolated guest network (with cell connection disabled) and seeing its DNS queries show up in the pihole log, and the phone not having any internet issues. I'll be honest, it's been a while since I set up the pihole, so I've kind of forgotten how I accomplished this DNS configuration, to get the isolated guest net to use the internal DNS server, but it does work. I believe it was a combination of setting the router's DHCP DNS server to the pihole, disabling the router from advertising itself as a DNS, and using DNS filtering ("DNS Director").

At any rate, all of that being said, I changed the guest SSID and it did not change the behavior of the devices.

Thanks, I appreciate your input.

 

[drinkingbird]

I should mention is that I've primarily been monitoring the issue by watching the client list modal on the main "Network Map" page, using the "Interface" grouping. This list updates roughly every 3 seconds, and the devices never leave the primary SSID's 2.4GHz group. I also just checked the "System Log -> Wireless Log" page and I see the same behavior.

If they are attempting to connect to the guest SSID and failing then this might make sense. However the other thing I should have mentioned is that the guest SSID and password have both remained unchanged. So in theory, even if they are trying to auto connect to the guest SSID, they really should be succeeding.

I probably also failed to mention that DNS is functioning on the isolated guest network. So if they were successfully connecting to the guest SSID, they should not be dropping due to a lack of DNS. DNS is being successfully passed from even the isolated guest network to the pihole on the primary network, which is proven by forcing my phone onto the isolated guest network (with cell connection disabled) and seeing its DNS queries show up in the pihole log, and the phone not having any internet issues. I'll be honest, it's been a while since I set up the pihole, so I've kind of forgotten how I accomplished this DNS configuration, to get the isolated guest net to use the internal DNS server, but it does work. I believe it was a combination of setting the router's DHCP DNS server to the pihole, disabling the router from advertising itself as a DNS, and using DNS filtering ("DNS Director").

At any rate, all of that being said, I changed the guest SSID and it did not change the behavior of the devices.

Thanks, I appreciate your input.

Perhaps your somewhat unknown DNS setup has some sort of loop in it requiring queries to go via the guest interface, and when you block that it fails. Or just the creation of the two VLANs and subnets that occurs when you disable intranet from guest is interfering, some config you don't remember is tied to that etc. Honestly at this point you might want to hard factory reset the router and start from scratch. Alternatively another test you can try is moving to guest 2 or 3 which will not create VLANs and subnets for guests when you disable intranet access (though it will still block traffic with firewall rules).

Basically there is no reason that guest config should impact your main LAN at all so it has to be something related to an addon, script, custom config, etc. Given your description above I'm leaning toward something related to your pihole setup.

 

[mmseng]

It certainly could be, though the DNS configuration has not changed since moving the devices from the guest net (where they were working) to the LAN. FWIW, while my configuration is perhaps unusual, I've not made any config changes to the router outside of the GUI, aside from SSHing in to try restarting various services during troubleshooting. Pretty much the only reason I moved from stock ASUS firmware to Merlin is for that "DNS Director" functionality, which allowed me to force devices to use the pihole. Hilariously when I first set this up, I neglected to give the pihole an exemption, so it was in fact looping its own upstream DNS queries back to itself. But that was pretty obvious since it broke my entire network, flooded the pihole logs, and raised my rpi's temps by like 10°C or more, IIRC.

I had been avoiding this as these devices are kind of annoying to reset and reconfigure with their app, but I will try moving them back to the guest net to see if they still work there. If not, then I would agree that something with the router config is screwing with them, even though other devices have no issues with it.

P.S. are you aware of any documentation that explains the different behaviors of the 3 guest nets? I've heard they operate differently (and you just confirmed it), but I'd like to understand how. I keep seeing "YazFi" mentioned everywhere, and it looks like this might provide a little more control over the different guest networks, and maybe some insight into that question. I have not tried installing/using it yet though.

 

[drinkingbird]

It certainly could be, though the DNS configuration has not changed since moving the devices from the guest net (where they were working) to the LAN. FWIW, while my configuration is perhaps unusual, I've not made any config changes to the router outside of the GUI, aside from SSHing in to try restarting various services during troubleshooting. Pretty much the only reason I moved from stock ASUS firmware to Merlin is for that "DNS Director" functionality, which allowed me to force devices to use the pihole. Hilariously when I first set this up, I neglected to give the pihole an exemption, so it was in fact looping its own upstream DNS queries back to itself. But that was pretty obvious since it broke my entire network, flooded the pihole logs, and raised my rpi's temps by like 10°C or more, IIRC.

I had been avoiding this as these devices are kind of annoying to reset and reconfigure with their app, but I will try moving them back to the guest net to see if they still work there. If not, then I would agree that something with the router config is screwing with them, even though other devices have no issues with it.

P.S. are you aware of any documentation that explains the different behaviors of the 3 guest nets? I've heard they operate differently (and you just confirmed it), but I'd like to understand how. I keep seeing "YazFi" mentioned everywhere, and it looks like this might provide a little more control over the different guest networks, and maybe some insight into that question. I have not tried installing/using it yet though.

I'm not aware of any documentation about the different behavior, at least not detailed. It may exist though. I think I've written some up about it but can't find a succinct single post.

The basics for stock Asus (does not apply to YazFi):

Couple things that are consistent:
All 3 operate exactly the same if you have Access Intranet ENabled. They are just additional SSIDs for your main LAN with no filtering or segmentation (so basically fairly pointless other than being able to use a password that you can give to guests and can change often without having to update your own devices).
All 3 block inter-client communication within the guest network (AP Isolation enabled) when you DISable intranet access.

Where it differs is only when you have access intranet DISabled

GW1 creates two or three VLANs (VLAN 501/192.168.101.0/24 for 2.4ghz Guest1, VLAN 502/192.168.102.0/24 for 5ghz guest1, and on tri-band routers VLAN 503/192.168.103.0/24 for 5ghz-2 guest1)
The main reason for this is to have the ability to propagate this guest wireless to AiMesh nodes and have the segmentation "survive" across all nodes, this requires VLANs to work, and you can't span a single subnet across multiple VLANs. However as a side effect, it does provide a bit more security by having two layers of firewall, and a bit more flexibility should you want to modify those firewall rules with a script.
It uses ebtables and iptables to block communication to and from the main LAN. Some stuff is just identical rules with 2 layers of protection, other stuff is more granular in one or the other. For example ebtables allows all UDP, but iptables then filters it to only DHCP and DNS to the guest router interface.
So in summary, GW1 becomes a routed interface when you disable intranet access, different subnet, VLAN, and has to pass through the routing module/firewall on the Asus to communicate with anything.

GW2/3 do not create any VLANs and share your main LAN subnet, even if you disable intranet access. They will not propagate to aimesh nodes. Ebtables is the main filtering to block communication to the main LAN. Iptables is just barely involved to permit the clients to do DHCP and DNS but not ping/telnet etc to the router interface, so iptables is basically just protecting the router itself from guests, not your main LAN, that relies almost completely on ebtables (along with some arp blocking and broadcast filtering that comes with AP isolation).
In summary, there is no routing here (beyond normal routing to the internet), just essentially a port on the switch with some filtering applied to it.

Like I said above, all 3 will block inter-client communication within the guest network using AP isolation when intranet access is disabled.

You can see more details on the EBTABLES/IPTABLES rule differences here https://www.snbforums.com/threads/d...-network-not-working.85988/page-2#post-854834

Worth noting that the subnets for guest wireless 1 (192.168.x.x) are hardcoded, you can't control them and can't reserve DHCP leases, at least not in 386 code, not certain on 388 but I don't believe there either. They have 2 through 254 set for DHCP leases so you can't even safely set a static IP in them.

Of course all of these behaviors can be overridden with scripts.

 

[mmseng]

Thank you for the writeup(s). Based on that I feel like guest nets 2/3 probably don't help my current situation, but it's definitely enlightening.

I'm pretty far out of my lane, but also based on your linked post, it seems like the reason DNS works across the isolation (which is something that's a little mysterious to me) may be because it is allowed through both ebtables and iptables, where other communications are not.

I did move one of the devices back to the isolated guest net and it works fine again, while the others on the LAN wifi are still resetting.

I don't fully understand some of the other stuff in your linked post but I saw you mention a discrepancy with ARP (at least on the guest 2/3 nets). I'm wondering if this has anything to do with it, since I specifically noted some strange ARP behavior from the devices when I was Wiresharking. I may be getting into the weeds here, but I just took another look and the problematic devices seem to be ARP probing for their own reserved IP at regular intervals, which I assume makes sense, since they are repeatedly reconnecting. What's even stranger is that the device I moved back to the guest net works fine, but the rpi is frequently spamming out ARP requests asking who has this device's old reserved ip on the LAN. I suppose it could just be because Pihole and/or Home Assistant (both running in containers on the rpi) technically know this device's MAC and LAN-reserved IP and are looking for it, since it's no longer on that IP.

At any rate, this all seems moot since the devices work fine on the LAN wifi when the guest net is disabled or not isolated, and I'm out of my league at this point regardless. I appreciate your input, but unless I can think of something else to try (that doesn't involve wiping the router), I'll probably just live without a guest net for now and deal with the LEDs not working whenever I inevitably turn it on for guests. I do finally have a 2nd rpi coming soon so I may considering moving Home Assistant over to the guest network and putting all of my IoT back on that net.

 

[drinkingbird]

it seems like the reason DNS works across the isolation (which is something that's a little mysterious to me) may be because it is allowed through both ebtables and iptables, where other communications are not.

Correct

I did move one of the devices back to the isolated guest net and it works fine again, while the others on the LAN wifi are still resetting.

I don't fully understand some of the other stuff in your linked post but I saw you mention a discrepancy with ARP (at least on the guest 2/3 nets). I'm wondering if this has anything to do with it, since I specifically noted some strange ARP behavior from the devices when I was Wiresharking. I may be getting into the weeds here, but I just took another look and the problematic devices seem to be ARP probing for their own reserved IP at regular intervals, which I assume makes sense, since they are repeatedly reconnecting. What's even stranger is that the device I moved back to the guest net works fine, but the rpi is frequently spamming out ARP requests asking who has this device's old reserved ip on the LAN. I suppose it could just be because Pihole and/or Home Assistant (both running in containers on the rpi) technically know this device's MAC and LAN-reserved IP and are looking for it, since it's no longer on that IP.

At any rate, this all seems moot since the devices work fine on the LAN wifi when the guest net is disabled or not isolated, and I'm out of my league at this point regardless. I appreciate your input, but unless I can think of something else to try (that doesn't involve wiping the router), I'll probably just live without a guest net for now and deal with the LEDs not working whenever I inevitably turn it on for guests. I do finally have a 2nd rpi coming soon so I may considering moving Home Assistant over to the guest network and putting all of my IoT back on that net.

ARP can be very odd to watch. It won't always make sense. If you fire up the Asus GUI and open client list, and then watch your sniffer you'll see the router ARP scanning the whole network every few minutes. Some devices do gratuitous ARPs (announcing their MAC when nobody has asked). Others will ARP an IP assigned to them by DHCP to make sure it isn't in use.

The odd behavior I was seeing was looking at the ARP table on devices themselves and seeing "incomplete" even though I had disabled AP isolation and there was no reason they should not have been able to ARP for the other device. This was confirmed in the sniffer by seeing it ask and getting no response. That is something that appears to be done somewhere in the driver or firmware for GW2 and 3, I didn't spend a lot of time troubleshooting it to really figure it out.

I honestly think what you're seeing is some sort of DNS loop or some configuration that is still tied to the guest network that you're not realizing. But if you don't want to go through a reset and reconfigure, and are ok with not having the guest, then you can run that way until you're ready to look into it more.

In normal operation there is absolutely nothing in the guest config (regardless of 1, 2, or 3) that should have any impact on the main LAN. The only possible thing I can think is if you have a device hardwired to the router and that device is VLAN aware, it will start seeing tagged frames coming out of that port once you enable GW1 with intranet disabled, but if you haven't configured the VLANs on it, it will just discard them so that should not be an issue either.

Home Assistant is another challenge as its discovery will typically rely on clients being on the same subnet and being able to reply (and in some cases even needing those clients to be able to initiate a connection).

Guest networks and IOTs are a bit of a problem. Sometimes it can be made to work, sometimes you need to do scripting, and other times it just isn't worth it.

At the very least I'd fire up maybe guest 2 or 3 with a tottally new SSID and password just to see what happens. If that has no negative impact, then turn that off and put that same new SSID/PW on GW1. That should at least tell you if it is simply enabling the guest that is a problem, or if it is a device that may be remembering a guest SSID.

 

[mmseng]

I would have guessed that if the issue was the devices remembering the guest net, then changing the guest SSID would have made a difference. But to be fair I wasn't particularly thorough in my testing after changing the SSID. When I get some more time I'll give it another shot and also try out the 2nd/3rd guest nets.

Thanks for the discourse.

 

[macster2075]

I have this issue as well. It doesn't matter which Guest Network I use, 1-3 or what type of SSID or password. If Intranet Access is disabled, it blocks Internet access altogether. As soon as I enable it, then Internet access comes back. I don't remember it being this way in the past.