Guest Network IP

[macster2075]

Hello...
There is no issue at all, I just have a question regarding Guest Network's IP.
I noticed that Guest Network #1 is in the range IP of 192.168.1.100.1, but guest #2 & #3 are on 192.168.1.1.
Why is that? and what's the difference?

Thanks.

 

[dave14305]

Being able to use Guest Network #1 on AiMesh nodes.

 

[eibgrad]

This guest network situation has been bugging me for quite some time, esp. since ASUS made some changes to (presumably) accommodate AiMesh. FWIW, here's what I'm seeing on my ASUS RT-AC68U. Since that's the only router I have at the moment, I can't say for sure if this applies across all ASUS routers.

To keep things simple, I'm only going to refer to the 2.4GHz range at the moment. And besides, whatever I have to say about the 2.4GHz range applies similarly to the 5GHz range. They're basically a mirror image of each other.

If I enabled Guest #1 on 2.4GHz, and intranet access is disabled, I get an error message in response to the wifi connection attempt of "incorrect password". Of course, it *is* correct, but the router is purposely denying me access. It will only permit access to Guest #1 if I also enable intranet access.

And w/ Guest #1 configured as above (intranet disabled), here's the dump of the bridging table and ifconfig for br1 (192.168.101.x).

admin@lab-merlin1:/tmp/home/root# brctl show
bridge name    bridge id        STP enabled    interfaces
br0        8000.1cb72ccb0960    yes        vlan1
                            eth1
                            eth2
br1        8000.1cb72ccb0961    yes        wl0.1
                            eth0.501
                            eth1.501
                            eth2.501

admin@lab-merlin1:/tmp/home/root# ifconfig br1
br1       Link encap:Ethernet  HWaddr 1C:B7:2C:CB:09:61
          inet addr:192.168.101.1  Bcast:192.168.101.255  Mask:255.255.255.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:225 errors:0 dropped:0 overruns:0 frame:0
          TX packets:264 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:10350 (10.1 KiB)  TX bytes:16384 (16.0 KiB)

Notice the the VAP (virtual AP) for Guest #1 (wl0.1) is assigned to the br1 bridge, which is configured w/ 192.168.101.x. And there are several other network interfaces assigned to that same bridge, presumably related to AiMesh.

Clearly the router is purposely locking me out under these conditions w/ some bogus error condition (which in and of itself is very confusing).

If I then enable intranet access on Guest #1, I get connected, no problem. And here's the dump of the bridging table and ifconfig for br1 again.

admin@lab-merlin1:/tmp/home/root# brctl show
bridge name    bridge id        STP enabled    interfaces
br0        8000.1cb72ccb0960    yes        vlan1
                            eth1
                            eth2
                            wl0.1

admin@lab-merlin1:/tmp/home/root# ifconfig br1
ifconfig: br1: error fetching interface information: Device not found

Guest #1's VAP (wl0.1) is bound to the private network (br0), and sure enough I get assigned an IP from the private network (192.168.1.x). And I have access to resources on the private network. And the br1 bridge and 192.168.101.x network vanish.

At no time do I ever receive an IP from the br1 bridge and its 192.168.101.x network. If I get connected at all, I *always* receive an IP from the private network. The same goes for Guest #2 and Guest #3. I can choose to have intranet access enabled or disabled (and both work as expected), and I'm assigned an IP from the private network (192.168.1.x), since those VAPs (wl0.2 and wl0.3) are also bridged to br0.

admin@lab-merlin1:/tmp/home/root# brctl show
bridge name    bridge id        STP enabled    interfaces
br0        8000.1cb72ccb0960    yes        vlan1
                            eth1
                            eth2
                            wl0.1
                            wl0.2
                            wl0.3

Note, I never get an incorrect password message w/ Guest #2 or Guest #3. This is strictly an issue w/ Guest #1. If I follow the same steps w/ the 5GHz band, it's exactly the same results, except the relevant bridge is br2, and the network is 192.168.102.x. But the behaviors are exactly the same.

So what's it all mean?

Presumably ASUS has mucked w/ Guest #1 for the benefit of AiMesh. And it's best that you avoid it, since to even use it requires you enable intranet access. I suppose if you have a situation where you want that type of access, it'll work. But for most ppl, Guest #1 is, for all intents and purposes, off limits for anyone but AiMesh users. Stay away from it and you'll be a happy camper.

And for anyone who was under the impression that ASUS was providing isolation at the ethernet/IP level because of these 192.168.101.x and 192.168.102.x networks, that's not happenin'. At least not on my RT-AC68U, and normal AP access. I can only assume disabling of intranet access on Guest #2 and Guest #3 is implemented using a layer 2 firewall (e.g., ebtables). And I personally don't like that approach. With intranet access disabled, it still allows network discovery of (if not necessarily access to) resources on the private network. I would have much preferred the 192.168.101.x and 192.168.102.x networks be used for guests, thus providing isolation at both the ethernet and IP levels. To mind, this is a noteworthy disadvantage when it comes to ASUS guest networks, which has now been compounded further by all this messing w/ Guest #1. Ugg.

Again, it's entirely possible other ASUS hardware behaves differently from my RT-AC68U. But my primary interest was finally getting to the bottom of these 192.168.101.x and 192.168.102.x networks. I think you can safely ignore them unless you're dealing w/ them from the perspective of AiMesh (I don't use it, so I can only speculate as to their usage). But it sure appears to me that br1/192.168.101.x and br2/192.168.102.x are AiMesh guest networks given they are otherwise inaccessible.

I'd be interested if other users w/ other hardware are seeing anything different in terms of guest networking behavior.

 

[john9527]

I can only assume disabling of intranet access on Guest #2 and Guest #3 is implemented using a layer 2 firewall (e.g., ebtables).

True (at least was true on earlier levels). Made intranet isolation easier to implement as things like networkmap, dnsmasq and I suspect some of the wireless were all coded to support only a single subnet.

 

[itpp20]

Use the firewall to block (guest wifi) access to any subnet (LAN), I posted a screen dump here somewhere how this will look like.

 

[eibgrad]

Use the firewall to block (guest wifi) access to any subnet (LAN), I posted a screen dump here somewhere how this will look like.

I assume you're referring to Guest #1. You can't access Guest #1 unless you agree to enable intranet access. But like Guest #2 and Guest #3, Guest #1 shares the same ethernet + IP network as the private network (br0). And therefore the IP firewall is of no use. Any such firewall would have to be a layer 2 (ethernet) firewall, similar to that used w/ Guest #2 and Guest #3 (e.g., ebtables). If that's what you're referring to, and have something that works, that's great.

 

[itpp20]

Isolation works per subnet but not between subnets, I prefer to keep guests to see each other and the gateway address which is on a different subnet while all other ranges are blocked. This is a clear Wifi/LAN separation and does not mix with guests who may be on the LAN. If anything else if going on then yes the firewall won't work in your case.

 

[ColinTaylor]

@eibgrad The (strange) way the guest networks work has been widely discussed in these forums since the Asus developer first created a beta thread for AiMesh 2.0 back in 2020 (or was it 2019) and asked forums members to test it. That said, the problems people have reported with LAN isolation not working properly does seem to be a bug in the current stock firmware. The LAN isolation was working fine in the past and still works on my router running Merlin's firmware. I have no issues regarding passwords not being accepted.

EDIT: See @gat0rdave's post here and his following post where he explains that the 501 and 502 interfaces are used to put VLAN tags on the guest network traffic so that they can be propagated to the AiMesh nodes.

 

[eibgrad]

@eibgrad The (strange) way the guest networks work has been widely discussed in these forums since the Asus developer first created a beta thread for AiMesh 2.0 back in 2020 (or was it 2019) and asked forums members to test it. That said, the problems people have reported with LAN isolation not working properly does seem to be a bug in the current stock firmware. The LAN isolation was working fine in the past and still works on my router running Merlin's firmware. I have no issues regarding passwords not being accepted.

EDIT: See @gat0rdave's post here and his following post where he explains that the 501 and 502 interfaces are used to put VLAN tags on the guest network traffic so that they can be propagated to the AiMesh nodes.

Thanks. Good information. But the fact remains, these changes by ASUS are ridiculously convoluted. And it leads to equally convoluted proposed workarounds. I personally don't want to get anywhere near it. IMO, ASUS should have come up w/ a completely different solution that left guest networks as they were. As I've stated many times before, I've never been enamored w/ the ASUS guest implementation to begin with. I consider it a serious weakness w/ these ASUS routers. AiMesh has only further aggravated the situation.