What's new

How to let Devices see each other in Guest network?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

N

nikr

Guest
Hello,

I recently switched to Asus router and have two questions about Guest network. I am running asuswrt-merlin on ax86u

1. I see Guest network 1 gets its own DHCP range where as guest network 2 shares IP addresses from the main network DHCP pool. why? While its not an issue as long it works but, can it be changed so that it gets its own IP range?

2. I an using Guest network 2 for all my IOT devices. For this particular network I would devices to be able to see each other but not have access to intranet. Reason being it makes it easy to add new device to IOT network and also some of the devices need phone and device to be able to see each other for firmware update to work.
 
YazFi is exactly what I was looking for. Unfortunately it seems, once enabled, clients connected to guest network no longer shows up under Network Map -> client list. Is there a way to fix it?
 
YazFi is exactly what I was looking for. Unfortunately it seems, once enabled, clients connected to guest network no longer shows up under Network Map -> client list. Is there a way to fix it?

I don't use it, but it doesn't surprise me if that's the case. Once you resort to third-party scripting, you're necessarily working outside the GUI. And those kinds of niceties are often sacrificed.
 
If you look at the Wireless log. You can see your clients there, other than that. No other way to see them connected
 
YazFi is exactly what I was looking for. Unfortunately it seems, once enabled, clients connected to guest network no longer shows up under Network Map -> client list. Is there a way to fix it?
I guess you should ask this directly to @Jack Yaz
 
If you look at the Wireless log. You can see your clients there, other than that. No other way to see them connected

You can also see them in LOG under DHCP leases.
 
YazFi is exactly what I was looking for. Unfortunately it seems, once enabled, clients connected to guest network no longer shows up under Network Map -> client list. Is there a way to fix it?
See System Log > Wireless Log in the Asus-Merlin GUI Admiration interface.

Or issue the SSH command: cat /var/lib/misc/dnsmasq.leases

Any further YazFi questions should probably be put in the YazFi 4.x thread: https://www.snbforums.com/threads/yazfi-v4-x.70308/

And post 17 of the YazFi 4.x thread answered your question too. ;-)
 
Last edited:
Is the guest device isolation a new thing? I was running stock Asus firmware and two days ago updated. Prior to the Asus update I was using a wireless guest network for my google home and chromecast devices with my phone and laptops on the same network. I had no problem casting, accessing the printer etc. After the firmware update this stopped working. I thought Asus borked something so I switch to Merlin but it is the same. I can't setup the Google home anymore when connecting to a guest network, I get a message about AP isolation and turning it off.

I have read the replies above and will check out the YazFi, but as my first question asks - is the guest isolation a new thing? Why was it working for me before?

Thanks!
 
Is the guest device isolation a new thing?
The Asus and Asus-Merlin firmware has had the option to block Guest WiFi clients from accessing the intranet (local LAN) via the Access Internet setting in the Guest WiFi configuration. Further there is a general WiFi option buried in the Advanced Settings > Wireless > Professional tab called Set AP Isolated. Both of these these appear to be broad settings that affect all WiFi clients. This is how the embedded ? info popup describes each one in the Asus firmware:
Access Intranet
Allow guest to access intranet.

Set AP Isolated
When this feature is enabled, wireless clients or devices will not be able to communicate with each other. You may want to utilize this feature if you have many guests that frequent your wireless network.
It appears the difference with Merlin and the use of YazFi is one can leave the settings Access Intranet and Set AP Isolated at their default settings (not enabled), and access the YazFi configuration to enable the Client Isolation setting. This setting applies Client Isolation only on the specific YazFi Guest Network. In other words a more granular approach that doesn't affect non Guest WiFi clients and or that doesn't affect the other YazFi Guest WiFi networks if used.
Client isolation
Should Guest Network radio prevent clients from talking to each other?
Edit to add: Some IoT device features won't work if one enabled the YazFi Client Isolation option or if one enables the Asus or Asus-Merlin Set AP Isolated option. Some IoT devices need to be able to communicate with each other for certain features to work. For example the Amazon Echo combine speakers feature won't work for me if I enable any sort of client isolation so the Echo devices cannot communicate with each other on the local (WiFi) network.
 
Last edited:
Thanks bennor for your reply!

I indeed use the Guest network so that I can isolate the clients from my intranet, but I don't wish to isolate them from each other. I found the setting for AP Isolation in the professional tab and it was, and is, set to 'no'. I also just tested moving my phone and Google home to the regular wifi network (not a guest network) and the setup worked fine, they can talk to each other and the setup can complete.

What I see from this is that when connected to the main wifi network the clients are not isolated from each other. When the clients are on a guest network I have the problem that they are isolated from each other - even though the setting in the professional tab is set to no.

Is this the expected behaviour? Is there any other way I can remove the isolation that is happening between clients on a guest network?

Thanks again!
 
Thanks bennor for your reply!

I indeed use the Guest network so that I can isolate the clients from my intranet, but I don't wish to isolate them from each other. I found the setting for AP Isolation in the professional tab and it was, and is, set to 'no'. I also just tested moving my phone and Google home to the regular wifi network (not a guest network) and the setup worked fine, they can talk to each other and the setup can complete.

What I see from this is that when connected to the main wifi network the clients are not isolated from each other. When the clients are on a guest network I have the problem that they are isolated from each other - even though the setting in the professional tab is set to no.

Is this the expected behaviour? Is there any other way I can remove the isolation that is happening between clients on a guest network?

Thanks again!
One obvious troubleshooting step, if you haven't done so already, is to do a hard reset on the Asus router, could be something got wonky if one upgraded the firmware in the past.

Are all the guest wifi devices on the same Guest Network? In other words all on the same 2.4Ghz or 5Ghz single network? Or are they spread across multiple guest networks?

Are you using the AIMesh feature on the Asus router?

Another troubleshooting step is if one is using Guest Network #1 for all their guest WiFi devices. Try using Guest Network #2 (or #3) instead for all guest WiFi devices. Apparently the Asus firmware/code may use (if I understand past discussions here) Guest WiFi #1 for the Mesh network connections.
 
I also remember reading somewhere that Asus has hard-coded isolation in guest networks. Which would explain why main works and not on guest.
 
Hi, I would also like devices on my guest network to be able to see and access one another but not devices on my other wireless network or LAN. Has any native solution been found in the past 7 months since question was first asked? Thank you!
 
Hi, I would also like devices on my guest network to be able to see and access one another but not devices on my other wireless network or LAN. Has any native solution been found in the past 7 months since question was first asked? Thank you!

What you're dealing with here is a fundamental limitation in how guest networks are implemented w/ ASUS routers, be it the oem/stock firmware or Merlin. Because guests share the *same* IP network as the private network (e.g., 192.168.1.x), there's no practical means to provide access to *some* devices and NOT others. So ASUS just makes it an all or nothing proposition; either everything is available, or nothing is available. Ugg.

Just to illustrate, I enabled all my guest networks and configured intranet access as Disabled. Here's a dump of the ethernet (layer2) firewall (ebtables).

Code:
admin@lab-merlin1:/tmp/home/root# ebtables -t broute -L
Bridge table: broute
Bridge chain: BROUTING, entries: 18, policy: ACCEPT
-p IPv4 -i wl0.2 --ip-dst 192.168.1.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl0.2 --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.2 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl0.3 --ip-dst 192.168.1.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl0.3 --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.3 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl1.2 --ip-dst 192.168.1.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl1.2 --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl1.2 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl1.3 --ip-dst 192.168.1.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl1.3 --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl1.3 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl0.1 --ip-dst 192.168.101.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl0.1 --ip-dst 192.168.101.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.1 --ip-dst 192.168.101.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl1.1 --ip-dst 192.168.102.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl1.1 --ip-dst 192.168.102.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl1.1 --ip-dst 192.168.102.0/24 --ip-proto tcp -j DROP

Notice that guest #1 (wl0.1 and wl1.1) is different in that it does NOT use the private network (192.168.1.x). But that's only because ASUS messed w/ that guest network for the sake of AiMesh. Any attempt by a wireless client to connect to guest #1 while intranet access is disabled will be prevented, since the router knows it can't prevent access to the 192.168.1.x network given the rules are specific to 192.168.101.x (2.4GHz) and 192.168.102.x (5GHz).

Prior to these AiMesh changes, guest #1 (wl0.1/wl1.1) would appear just the same as guest #2 (wl0.2/wl1.2) and guest #3 (wl0.3/wl1.3). Access is either all allowed or all denied. There is NO DISCRIMATION possible! Not unless YOU want to go into ebtables and start adding rules to allow specific device-to-device communications. To say that's rather tedious is an understatement.

This is why I despise this form of guest network. The better option is to place guests on a *different* IP network. And now you can allow communications between devices that share that same IP network, but still provide an *IP* firewall to prevent routing from one network to the other by default, w/ perhaps an exception here and there (e.g., allow access from a guest network to a printer on the private network).

That's why my recent VLANs script for the ASUS RT-AC68U places all new VLANs on their own IP network. Now you don't have these types of problems.


But like anything involving scripting, when it's NOT native to the GUI, there are limitations. Some things won't work w/ the GUI (e.g., static leases), since the GUI is unaware of these underlying changes.

This is why I constantly harp on why it matters what firmware you use. ALL firmware has its advantages and disadvantages. And in the case of guest networks, I consider using the same IP network for the private and guest networks a significant disadvantage. It's one of several reasons I personally do NOT use ASUS oem/stock or Merlin for my primary router (although I do use it for other purposes, and for some of my customers who don't have the same concerns). The lack of VLANs support and the guest implementation are deal breakers, at least for *me*. Instead, I use FT (FreshTomato) where I don't have any of these problems. Of course, I then lose access to some nice features otherwise only available w/ Merlin. But no matter what firmware you choose, you always gain and lose something.
 
If you look at my posts, I have previously written about this. You can set variable ap_isolate = 0 and then your IoT devices can communicate to each other. You don't need scripts. Just keep in mind that each time you save your guest network settings, it will set this variable back to 1 (a value of 1 means isolation is turned on).

To check AP Isolation use command:

nvram show | grep isolate

This will show all your wireless networks:

size: 66432 bytes (64640 left)
wl0.1_ap_isolate=0
wl0.2_ap_isolate=1
wl0.3_ap_isolate=0
wl0_ap_isolate=0
wl1.1_ap_isolate=0
wl1.2_ap_isolate=0
wl1.3_ap_isolate=0
wl1_ap_isolate=0
wl_ap_isolate=0

wl0.x are the 2.4 Ghz guest networks and wl1.x are the 5 Ghz guest networks.

To change, as an example the 1st wireless network 5 Ghz:

nvram set wl1.1_ap_isolate=0

nvram commit

reboot
 
If you look at my posts, I have previously written about this. You can set variable ap_isolate = 0 and then your IoT devices can communicate to each other. You don't need scripts. Just keep in mind that each time you save your guest network settings, it will set this variable back to 1 (a value of 1 means isolation is turned on).

To check AP Isolation use command:

nvram show | grep isolate

This will show all your wireless networks:

size: 66432 bytes (64640 left)
wl0.1_ap_isolate=0
wl0.2_ap_isolate=1
wl0.3_ap_isolate=0
wl0_ap_isolate=0
wl1.1_ap_isolate=0
wl1.2_ap_isolate=0
wl1.3_ap_isolate=0
wl1_ap_isolate=0
wl_ap_isolate=0

wl0.x are the 2.4 Ghz guest networks and wl1.x are the 5 Ghz guest networks.

To change, as an example the 1st wireless network 5 Ghz:

nvram set wl1.1_ap_isolate=0

nvram commit

reboot
This worked, thanks!
 
What you're dealing with here is a fundamental limitation in how guest networks are implemented w/ ASUS routers, be it the oem/stock firmware or Merlin. Because guests share the *same* IP network as the private network (e.g., 192.168.1.x), there's no practical means to provide access to *some* devices and NOT others. So ASUS just makes it an all or nothing proposition; either everything is available, or nothing is available. Ugg.

Just to illustrate, I enabled all my guest networks and configured intranet access as Disabled. Here's a dump of the ethernet (layer2) firewall (ebtables).

Code:
admin@lab-merlin1:/tmp/home/root# ebtables -t broute -L
Bridge table: broute
Bridge chain: BROUTING, entries: 18, policy: ACCEPT
-p IPv4 -i wl0.2 --ip-dst 192.168.1.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl0.2 --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.2 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl0.3 --ip-dst 192.168.1.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl0.3 --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.3 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl1.2 --ip-dst 192.168.1.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl1.2 --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl1.2 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl1.3 --ip-dst 192.168.1.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl1.3 --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl1.3 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl0.1 --ip-dst 192.168.101.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl0.1 --ip-dst 192.168.101.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.1 --ip-dst 192.168.101.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl1.1 --ip-dst 192.168.102.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl1.1 --ip-dst 192.168.102.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl1.1 --ip-dst 192.168.102.0/24 --ip-proto tcp -j DROP

Notice that guest #1 (wl0.1 and wl1.1) is different in that it does NOT use the private network (192.168.1.x). But that's only because ASUS messed w/ that guest network for the sake of AiMesh. Any attempt by a wireless client to connect to guest #1 while intranet access is disabled will be prevented, since the router knows it can't prevent access to the 192.168.1.x network given the rules are specific to 192.168.101.x (2.4GHz) and 192.168.102.x (5GHz).

Prior to these AiMesh changes, guest #1 (wl0.1/wl1.1) would appear just the same as guest #2 (wl0.2/wl1.2) and guest #3 (wl0.3/wl1.3). Access is either all allowed or all denied. There is NO DISCRIMATION possible! Not unless YOU want to go into ebtables and start adding rules to allow specific device-to-device communications. To say that's rather tedious is an understatement.

This is why I despise this form of guest network. The better option is to place guests on a *different* IP network. And now you can allow communications between devices that share that same IP network, but still provide an *IP* firewall to prevent routing from one network to the other by default, w/ perhaps an exception here and there (e.g., allow access from a guest network to a printer on the private network).

That's why my recent VLANs script for the ASUS RT-AC68U places all new VLANs on their own IP network. Now you don't have these types of problems.


But like anything involving scripting, when it's NOT native to the GUI, there are limitations. Some things won't work w/ the GUI (e.g., static leases), since the GUI is unaware of these underlying changes.

This is why I constantly harp on why it matters what firmware you use. ALL firmware has its advantages and disadvantages. And in the case of guest networks, I consider using the same IP network for the private and guest networks a significant disadvantage. It's one of several reasons I personally do NOT use ASUS oem/stock or Merlin for my primary router (although I do use it for other purposes, and for some of my customers who don't have the same concerns). The lack of VLANs support and the guest implementation are deal breakers, at least for *me*. Instead, I use FT (FreshTomato) where I don't have any of these problems. Of course, I then lose access to some nice features otherwise only available w/ Merlin. But no matter what firmware you choose, you always gain and lose something.
Thanks for your detailed response. Managing VLANs through GUI would be valuable for me. What drew me to Merlin was the VPN routing, and the ability to have multiple Open VPN clients and pick and choose which devices go through which tunnel. Can FT do that? Changing firmware seems like a drag, but maybe I'll give FT a go next time around.
 
Hi

Waking up this thread since there was quite good answers the the questions posted. I need to be able to allow clients to communicate to each other between GN1 (2.4Ghz) and GN2 (5Ghz). How do I do it? the .isolate=0 only allows within the same net. But GN1 has 192.168.101.x while GN2 has 192.168.102.X.
 
Hi

Waking up this thread since there was quite good answers the the questions posted. I need to be able to allow clients to communicate to each other between GN1 (2.4Ghz) and GN2 (5Ghz). How do I do it? the .isolate=0 only allows within the same net. But GN1 has 192.168.101.x while GN2 has 192.168.102.X.
If one uses YazFi its possible:

https://github.com/jackyaz/YazFi#custom-firewall-rules

Note that YazFi doesn't support AiMesh nodes.
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top