Repeater connected to Guest SSID bypassing Access Intranet = Disable

[Jack Yaz]

Thank you!
I actually tried both wired and wireless clients on the repeater. Both work.

Well the LAN ports working is even more of a concern as they shouldn't be active in WiFi repeater mode (by my definition of a repeater, anyway).

 

[L&LD]

Just wondering what the outcome would be if you used 'Access Point (AP) mode / AiMesh Router in AP mode' instead?

 

[john9527]

Just wondering what the outcome would be if you used 'Access Point (AP) mode / AiMesh Router in AP mode' instead?

That is known not to work since the parent router sees anything connected to the access point as being a wired connection. Long standing limitation of AP and Guest Networks.

 

[john9527]

Out of interest, I tested with a TP-Link repeater connected to a guest ssid on my LTS fork (AC68). That worked as expected and connecting to it maintained the guest isolation. I'll try to test with another AC68 as a repeater later today.

EDIT: Tested with an AC68 also on my fork. Clients connected to it remain isolated as well.

 

[L&LD]

I am wondering specifically for AiMesh v2.0 though, not anything older (and in AiMesh Router in AP mode too).

 

[eibgrad]

Well the LAN ports working is even more of a concern as they shouldn't be active in WiFi repeater mode (by my definition of a repeater, anyway).

But the term repeater gets fuzzy when you're talking about a device that's normally a router w/ an integrated switch. The question becomes, if the switch is there, why not use it? There's no particular reason this should present a problem since the wireless client and wired ports of the repeater are simply bridged. From the perspective of the remote AP, wired and wireless clients over the repeater are indistinguishable. And sure enough, whatever is causing clients of the repeater to have access to the private network of the primary router is affecting both. That's why there's every indication this is a problem w/ the primary router and its handling of guest networks, NOT the repeater. What precisely that is the 64k question.

When I use my RT-AC68U as the primary router and create a guest network, it *always* creates a new IP network and bridge (e.g., br1). And if the guest network is defined to NOT allow intranet access, I can verify via a dump of the firewall that access from br1 to the private network (br0) is denied. So I see no way a wireless client of the guest network's AP (or by extension, and wired or wireless clients of a repeater) could gain access to the private network.

All that said, if the guest network is implemented using the *same* IP network as the private network (which is the case w/ certain routers), NOW you might be in trouble, because this has to be enforced at the ethernet level (presumably using ebtables), where normally no such isolation exists.

What I'm wondering is if the problem has to do w/ whether the repeater is using WDS rather than standard wifi. In the latter case, the only MAC address ever seen by the remote AP is that of the wireless client itself. But in the case of WDS, the MAC addresses of the wired/wireless clients behind the wireless client of the repeater *are* seen by the remote AP. And if the remote AP is using MAC addresses for the purpose of isolation, whether that is why it's breaking down.

 

[john9527]

I am wondering specifically for AiMesh v2.0 though, not anything older (and in AiMesh Router in AP mode too).

Hmmm....interesting. Wonder if they are piggy-backing on top of the AiMesh wireless backhaul code for repeater mode and they missed something....

 

[ColinTaylor]

Well the LAN ports working is even more of a concern as they shouldn't be active in WiFi repeater mode (by my definition of a repeater, anyway).

As far as I know the LAN ports have always worked in repeater mode. Some people have even used repeater instead of media bridge mode because of bugs with media bridge mode.

 

[Jack Yaz]

As far as I know the LAN ports have always worked in repeater mode. Some people have even used repeater instead of media bridge mode because of bugs with media bridge mode.

That may be, but it conflicts what I'd expect it to do. Yes disabling them is a "waste" but its leaning towards an access point rather than repeater at that point

 

[hiluke88]

Out of interest, I tested with a TP-Link repeater connected to a guest ssid on my LTS fork (AC68). That worked as expected and connecting to it maintained the guest isolation. I'll try to test with another AC68 as a repeater later today.

EDIT: Tested with an AC68 also on my fork. Clients connected to it remain isolated as well.

Interesting. I'll try installing the 374 LTS fork on the repeater RT-AC68U and see what results I get. I suspect that it may need to be on the primary router though (which I won't be able to install on the RT-AX86U).

I am wondering specifically for AiMesh v2.0 though, not anything older (and in AiMesh Router in AP mode too).

I get the same issue when I have Merlin 384.19 installed on primary and repeater (which is not AiMesh 2.0).

When I use my RT-AC68U as the primary router and create a guest network, it *always* creates a new IP network and bridge (e.g., br1). And if the guest network is defined to NOT allow intranet access, I can verify via a dump of the firewall that access from br1 to the private network (br0) is denied. So I see no way a wireless client of the guest network's AP (or by extension, and wired or wireless clients of a repeater) could gain access to the private network.

All that said, if the guest network is implemented using the *same* IP network as the private network (which is the case w/ certain routers), NOW you might be in trouble, because this has to be enforced at the ethernet level (presumably using ebtables), where normally no such isolation exists.

What firmware/add-on/script are you running on your RT-AC68U? Every time I have enabled a guest network (on either stock or Merlin), they are always in the same subnet as the primary network, except for this latest 386.1 release, where index 1 for both 2.4GHz and 5GHz have their own subnet ranges. Unless I am confusing an IP network with a subnet?

 

[hiluke88]

Out of interest, I tested with a TP-Link repeater connected to a guest ssid on my LTS fork (AC68). That worked as expected and connecting to it maintained the guest isolation. I'll try to test with another AC68 as a repeater later today.

EDIT: Tested with an AC68 also on my fork. Clients connected to it remain isolated as well.

Okay I installed RT-AC68U_374.43_48E2j9527 on the repeater RT-AC68U and connected it to the primary running Merlin 386.1_2.
Initially this looked to be isolated properly, but after waiting for things to propagate properly, I still have access into the primary network.

 

[kernol]

Like @Jack Yaz I am puzzled that there is still intranet access across subnets when using his YazFi and configuring it as I had suggested above.
The repeater and any devices that attach to it should be issued with an ip address in the 192.168.53.0/24 range - the same ip subnet attached to the repeater itself. Unless something "bridges" the subnets - there should not be any traffic between them.

I note in your subsequent test setups - the repeater periodically gets an ip address within the main router ranger [192.168.22.0/24] - and that clearly would be a problem if trying to deny access to the intranet on that subnet.

Hopefully Jack will find time to do test setup and discover [if he can repeat your problem] what is creating a bridge between the subnets.
All beyond my pay-grade I'm afraid - good luck .

 

[hiluke88]

Just an update, I raised this issue with Asus, however it looks like they acknowledge that their Guest networks actually have no segregation.

In this case Guest Network SSID by name, but not actually as a Guest Network by function, which is why the whole network is accessible.

If anyone is looking to replicate this issue, it can be done with the following:
Primary router running a GUEST network (any slot or frequency), with access intranet disabled.

Repeater Setup:
Start with a wiped Asus router (factory default).
Connect to the ASUS_5G network, or directly to the router via Ethernet cable.
Go to 192.168.1.1 in a browser.
Click Advanced Settings.
Choose Operation Mode> Repeater mode.
Pick the GUEST network from the list and key in the GUEST password.
Pick Automatic IP.
Set 2.4GHz and 5GHz Repeater networks (e.g. STUDIO and STUDIO_5G).
Set router login name and password.
Wait for router to reboot.

Test: Connect PC to Primary Router SSID (or via Ethernet to primary router) and a second device to the STUDIO_5G SSID. The device on the STUDIO_5G network is able to discover and access the PC on the primary network - this is the issue.

 

[Christian_Haitian]

Just an update, I raised this issue with Asus, however it looks like they acknowledge that their Guest networks actually have no segregation.



If anyone is looking to replicate this issue, it can be done with the following:
Primary router running a GUEST network (any slot or frequency), with access intranet disabled.

Repeater Setup:
Start with a wiped Asus router (factory default).
Connect to the ASUS_5G network, or directly to the router via Ethernet cable.
Go to 192.168.1.1 in a browser.
Click Advanced Settings.
Choose Operation Mode> Repeater mode.
Pick the GUEST network from the list and key in the GUEST password.
Pick Automatic IP.
Set 2.4GHz and 5GHz Repeater networks (e.g. STUDIO and STUDIO_5G).
Set router login name and password.
Wait for router to reboot.

Test: Connect PC to Primary Router SSID (or via Ethernet to primary router) and a second device to the STUDIO_5G SSID. The device on the STUDIO_5G network is able to discover and access the PC on the primary network - this is the issue.

I've confirmed this bug as well. I do need a separate guest wireless network in my environment as I have family members who routinely visit and I don't trust most of their internet security habits. I haven't found a good way to workaround this issue using iptables either. I was looking forward to staying with Asus routers and asus-merlin firmware but this is a serious issue that I can't ignore. I'll have to seek an alternative wireless router solution. Interestingly enough that my old netgear wndr3700 with openwrt was much more secure in this similar setup.

 

[Christian_Haitian]

I decided to use another custom firmware (tomato) on an old retired rt68u and connect it to the existing asus merlin wireless guest network I’ve configured using YazFi and that seems to respect the disabled intranet configuration of my guest wireless. The issue seems to be using 2 asus wireless routers with asus (stock) or asus (merlin) firmware and setting one to repeat the other bypasses the guest network‘s configuration. This theory hasn’t been fully tested on my end so this is just based on my observations so far using asus (stock), asus (merlin), and tomato firmwares. This is something Asus should really resolve asap as this is a serious security threat for those that make use of the guest network feature thinking that it provides sufficient segregation from their main network. If the guest network feature must be used, be sure to set a good WPA2-AES password on it.

similar to hiluke88, I’ve reported this issue to Asus via this link below. I think it’s important that others report this as well that have been able to confirm this vulnerability.

ASUS Security Advisory

www.asus.com

 

[hiluke88]

I've confirmed this bug as well. I do need a separate guest wireless network in my environment as I have family members who routinely visit and I don't trust most of their internet security habits. I haven't found a good way to workaround this issue using iptables either. I was looking forward to staying with Asus routers and asus-merlin firmware but this is a serious issue that I can't ignore. I'll have to seek an alternative wireless router solution. Interestingly enough that my old netgear wndr3700 with openwrt was much more secure in this similar setup.

Thanks for replicating!

Yep, the only way I have found to prevent guests from accessing the primary network is to completely disable all guest networks in the Asus firmware. Otherwise if you leave a guest network enabled, you are leaving your primary network vulnerable.

If you want a segregated guest network on an Asus router, these are the only options I can think of:
1. Roll back your router firmware to John's LTS 374 firmware (not an option for newer Asus router models).
2. Remove AsusWRT/Merlin and use an alternate 3rd party firmware like DD-WRT.
3. Add a second router connected in AP mode that will broadcast the Guest SSID.

Open to other suggestions though!

 

[Christian_Haitian]

Thanks for replicating!

Yep, the only way I have found to prevent guests from accessing the primary network is to completely disable all guest networks in the Asus firmware. Otherwise if you leave a guest network enabled, you are leaving your primary network vulnerable.

If you want a segregated guest network on an Asus router, these are the only options I can think of:
1. Roll back your router firmware to John's LTS 374 firmware (not an option for newer Asus router models).
2. Remove AsusWRT/Merlin and use an alternate 3rd party firmware like DD-WRT.
3. Add a second router connected in AP mode that will broadcast the Guest SSID.

Open to other suggestions though!

I’m thinking of trying tomato on the main router as my main router is an Asus RT-1900P so it’s supported. My AX58U just acts as a wireless AP with an ethernet backhaul at the moment so it can stay with the asus merlin firmware. My concern is how much performance will I be giving up my going with an alternate custom FW solution as I think just asus stock and asus merlin have the hardware acceleration capabilities for these Asus routers. Hopefully it’s not too bad and can come back to Asus Merlin if the issue has been addressed.

 

[guetech]

It's now 2 years later and I have the exact same issue with AX86U (main, 388) + AX55 (repeater, 386).

Basically if someone knows your guest network password and buys an asus router they can get full access to your main network. This is a major flaw in my opinion and a shame that asus refuses to fix it, but personally I'm not too worried about that part. I just want to keep IOT stuff isolated somehow...


Edit: For reference here's what happens when the repeater connects to the main router:

Spoiler: log

wfd_registerdevice Successfully registered dev wds1.1.1 ifidx 2 wfd_idx 1
Register interface [wds1.1.1] MAC: a0:ab:fe:ef:ab:f5

device wds1.1.1 entered promiscuous mode
br0: port 11(wds1.1.1) entered listening state
br0: port 11(wds1.1.1) entered listening state
br0: port 11(wds1.1.1) entered learning state
br0: topology change detected, propagating
br0: port 11(wds1.1.1) entered forwarding state
device wds1.1.1 left promiscuous mode
br0: port 11(wds1.1.1) entered disabled state
netdev path : wds1.1.1.0 -> wds1.1.1
BCMVLAN : wds1.1.1 mode was set to RG
netdev path : wds1.1.1.501 -> wds1.1.1
BCMVLAN : wds1.1.1 mode was set to RG
device wds1.1.1.0 entered promiscuous mode
device wds1.1.1 entered promiscuous mode
br0: port 11(wds1.1.1.0) entered listening state
br0: port 11(wds1.1.1.0) entered listening state
br0: port 12(wds1.1.1) entered listening state
br0: port 12(wds1.1.1) entered listening state
device wds1.1.1.501 entered promiscuous mode
br1: port 9(wds1.1.1.501) entered listening state
br1: port 9(wds1.1.1.501) entered listening state
br0: port 12(wds1.1.1) entered disabled state
netdev path : wds1.1.1.502 -> wds1.1.1
BCMVLAN : wds1.1.1 mode was set to RG
br0: port 12(wds1.1.1) entered listening state
br0: port 12(wds1.1.1) entered listening state
device wds1.1.1.502 entered promiscuous mode
br2: port 9(wds1.1.1.502) entered listening state
br2: port 9(wds1.1.1.502) entered listening state
br0: port 11(wds1.1.1.0) entered learning state
br0: port 12(wds1.1.1) entered learning state
br0: topology change detected, propagating
br0: port 11(wds1.1.1.0) entered forwarding state
br0: topology change detected, propagating
br0: port 12(wds1.1.1) entered forwarding state
device br0 entered promiscuous mode
br1: port 9(wds1.1.1.501) entered learning state
br2: port 9(wds1.1.1.502) entered learning state
device br0 left promiscuous mode

Manually reconfiguring the assigment of the new wds* to the correct bridges does prevent intranet access, but that's not terribly convenient...

 

[JJay03]

I am experiancing this issue still as well. What about using AImesh and then with the Pro beta firmware I think you can disable ssid's from certain nodes.

 

[drinkingbird]

It's now 2 years later and I have the exact same issue with AX86U (main, 388) + AX55 (repeater, 386).

Basically if someone knows your guest network password and buys an asus router they can get full access to your main network. This is a major flaw in my opinion and a shame that asus refuses to fix it, but personally I'm not too worried about that part. I just want to keep IOT stuff isolated somehow...


Manually reconfiguring the assigment of the new wds* to the correct bridges does prevent intranet access, but that's not terribly convenient...

Asus did fix it, Guest Wireless 1 in AiMesh on 386 code base uses VLANs and dot1Q trunk to carry the isolation to nodes. WDS is old technology that is lacking support for many things and hasn't been updated in a while as far as I know.

If you just configure the repeater as standalone (not WDS) and join it to the guest network, it won't isolate clients from each other but should still block them from hitting your main LAN, though I haven't tried it personally.