Guest Network on 386 builds doesn't play nice with Chromecast, and a potential workaround

[JWoo]

I noticed that Chromecast is not working on build 386.1 Beta 1 on my RT-AX58U. I am using a Guest Network for IoT devices including all my Chromecast devices. Chromecast of course functions by allowing devices on the same WIFI network to connect to each other via casting. On the 386.1 Beta 1 build, devices like Google Home and Android TV (with build in Chromecast) cannot be cast to unless you open up your Guest Network completely by setting Access Intranet to ENABLE which then opens up your whole LAN to your IoT devices. This makes the Guest Network useless as a means to isolate your IoT devices from your LAN.

On the 384 builds, Chromecast works fine with guest network and intranet set to Disabled. The 384 builds worked as I would expect. This problem is new on all the 386 builds.

On the 386 builds, Asus redesigned the Guest Network function to also work with AIMesh. The first guest network uses subnet 192.168.101.0/24 for 2.4Ghz and 192.168.102.0/24 for 5Ghz. The other 2 guest networks use your main subnet. With the Intranet Disabled setting, Chromecast will not work. If you enable Access Intranet, Chromecast works but all your IoT devices have full run of your Intranet. Very bad. It seems like the new function is setting a parameter ap_isolate to a value of 1 when Access Intranet is disabled which renders Chromecast inoperable. The 384 builds had ap_isolate = 0 even when Access Intranet was Disabled.

To "fix" this, here is what I did using the first 5Ghz guest network (wl1.1) as an example:

nvram set wl1.1_ap_isolate=0
nvram commit
reboot

In my own testing, with ap_isolate=0 (same value as on the 384 builds), my Chromecast works, and the Guest Network is still isolated from the main network. This seems like a fault in the Asus Guest Network function in all the 386 builds. Parameter ap-isolate should not be changed to 1.

Is anyone else experiencing this same issue with a clean install of a 386 based build preventing Chromecast from working on a guest network?

 

[bbunge]

I noticed that Chromecast is not working on build 386.1 Beta 1 on my RT-AX58U. I am using a Guest Network for IoT devices including all my Chromecast devices. Chromecast of course functions by allowing devices on the same WIFI network to connect to each other via casting. On the 386.1 Beta 1 build, devices like Google Home and Android TV (with build in Chromecast) cannot be cast to unless you open up your Guest Network completely by setting Access Intranet to ENABLE which then opens up your whole LAN to your IoT devices. This makes the Guest Network useless as a means to isolate your IoT devices from your LAN.

View attachment 28364

On the 384 builds, On the 386 builds, run of your Intranet. Very bad. It seems like the new function is setting a parameter ap_isolate to a value of 1 when Access Intranet is disabled which renders Chromecast inoperable. The 384 builds had ap_isolate = 0 even when Access Intranet was Disabled.

To "fix" this, here is what I did using the first 5Ghz guest network (wl1.1) as an example:

nvram set wl1.1_ap_isolate=0
nvram commit
reboot

In my own testing, with ap_isolate=0 (same value as on the 384 builds), my Chromecast works, and the Guest Network is still isolated from the main network. This seems like a fault in the Asus Guest Network function in all the 386 builds. Parameter ap-isolate should not be changed to 1.

Is anyone else experiencing this same issue with a clean install of a 386 based build preventing Chromecast from working on a guest network?

Your issue is likely a result of Diversion. I had issues with Guest Network index 1 with Diversion installed. Removed Diversion and clients on Guest Network index 1 work as intended. The work around is to use Guest Network index 2 or 3 or remove Diversion.

 

[JWoo]

Not using Diversion. Plain vanilla Asus Merlin.

 

[Morris]

I noticed that Chromecast is not working on build 386.1 Beta 1 on my RT-AX58U. I am using a Guest Network for IoT devices including all my Chromecast devices. Chromecast of course functions by allowing devices on the same WIFI network to connect to each other via casting. On the 386.1 Beta 1 build, devices like Google Home and Android TV (with build in Chromecast) cannot be cast to unless you open up your Guest Network completely by setting Access Intranet to ENABLE which then opens up your whole LAN to your IoT devices. This makes the Guest Network useless as a means to isolate your IoT devices from your LAN.

View attachment 28364

On the 384 builds, Chromecast works fine with guest network and intranet set to Disabled. The 384 builds worked as I would expect. This problem is new on all the 386 builds.

On the 386 builds, Asus redesigned the Guest Network function to also work with AIMesh. The first guest network uses subnet 192.168.101.0/24 for 2.4Ghz and 192.168.102.0/24 for 5Ghz. The other 2 guest networks use your main subnet. With the Intranet Disabled setting, Chromecast will not work. If you enable Access Intranet, Chromecast works but all your IoT devices have full run of your Intranet. Very bad. It seems like the new function is setting a parameter ap_isolate to a value of 1 when Access Intranet is disabled which renders Chromecast inoperable. The 384 builds had ap_isolate = 0 even when Access Intranet was Disabled.

To "fix" this, here is what I did using the first 5Ghz guest network (wl1.1) as an example:

nvram set wl1.1_ap_isolate=0
nvram commit
reboot

In my own testing, with ap_isolate=0 (same value as on the 384 builds), my Chromecast works, and the Guest Network is still isolated from the main network. This seems like a fault in the Asus Guest Network function in all the 386 builds. Parameter ap-isolate should not be changed to 1.

Is anyone else experiencing this same issue with a clean install of a 386 based build preventing Chromecast from working on a guest network?

Placing your IOT devices in a separate SSID that is blocked from accessing the rest of your network is a recommended security practice. Your workaround violates this.

What you need to do is move your Chrome Casts to your production network. Also disable access intranet on the IOT SSID. Moving the Chrome Casts to to production It is a risk you need to take if you wish to use them.

Morris

 

[bbunge]

Not using Diversion. Plain vanilla Asus Merlin.

The work around is to use Guest Network index 2 or 3 for both 2.4 GHZ and 5 GHZ. There may be other factors at play besides Diversion.

 

[JWoo]

Placing your IOT devices in a separate SSID that is blocked from accessing the rest of your network is a recommended security practice. Your workaround violates this.

What you need to do is move your Chrome Casts to your production network. Also disable access intranet on the IOT SSID. Moving the Chrome Casts to to production It is a risk you need to take if you wish to use them.

Morris

For clarity, this issue did not exist on the 384 builds and "wl0.x_ap_isolate" and "wl1.x_ap_isolate" are set to 0 as the default on the 384 builds. I tested using both guest network 1 and 2 on the 386.1 Beta 1 build with Access Intranet set to Disable in the GUI and manually set wl1.1_ap_isolate=0 and wl1.2_ap_isolate=0. By doing this, Chromecast works and I also tested that a device on the guest network cannot access the main network. The ASUS code when you enable Access Intranet in the GUI seems to be a lot more than just a variable.

Think about it this way. If you have a guest network set up for an AirBnB room you are renting you want the guest network to:
a) be able to access Internet
b) Chromecast should work for the devices on the guest network
c) devices on the guest network should not be able to access the Intranet

As described above is exactly how it worked on the 384 code base. I think Asus has some errors in the new 386 code base.

You can test this workaround for yourself on the 386 code base by setting up a guest network with default values (including Access Intranet set to Disable) and then set in NVRAM the variable ap_isolate to 0. Once you've done that, try to access your main network and you won't be able to.

 

[Morris]

For clarity, this issue did not exist on the 384 builds and "wl0.x_ap_isolate" and "wl1.x_ap_isolate" are set to 0 as the default on the 384 builds. I tested using both guest network 1 and 2 on the 386.1 Beta 1 build with Access Intranet set to Disable in the GUI and manually set wl1.1_ap_isolate=0 and wl1.2_ap_isolate=0. By doing this, Chromecast works and I also tested that a device on the guest network cannot access the main network. The ASUS code when you enable Access Intranet in the GUI seems to be a lot more than just a variable.

Think about it this way. If you have a guest network set up for an AirBnB room you are renting you want the guest network to:
a) be able to access Internet
b) Chromecast should work for the devices on the guest network
c) devices on the guest network should not be able to access the Intranet

As described above is exactly how it worked on the 384 code base. I think Asus has some errors in the new 386 code base.

You can test this workaround for yourself on the 386 code base by setting up a guest network with default values (including Access Intranet set to Disable) and then set in NVRAM the variable ap_isolate to 0. Once you've done that, try to access your main network and you won't be able to.

I'm confused. A states guests can access the internet. C states guests can not access the internet.

 

[JWoo]

I'm confused. A states guests can access the internet. C states guests can not access the internet.

C states Intranet, meaning any other subnet on the router

 

[Morris]

C states Intranet, meaning any other subnet on the router

Ah, The old versions did had multiple issues with guest networks. I believe you need to attach your phone to the guest network and then use the Google Home App to configure your Chrome Cast for the network as it is in the new code. The Chrome Cast must be in the same SSID and broadcast domain as the host that will cast. You want the firewall separating the Guest network from the Intranet. (I hate that word!) Most security devices call it the inside network as do Network Engineers and Security Engineers.

Morris

 

[JWoo]

I've been using Chromecast on the 384 based Merlin since the early part of this year. I have all IoT devices including phones and tablets on the same guest network. And I agree with you, the guest network should be isolated from the inside network. It has worked like this on the 384 based Merlin since early this year.

The issue is that on the 386 code base, it appears that Asus has broken the guest network. Because if you isolate the guest network from inside network (GUI Setting "Access Intranet" = disabled), you lose the ability to use Chromecast. Setting the variable as I describe earlier appears to preserve the isolation of the guest network from the inside network while also allowing Chromecast to work.

I posted this to share a workaround and also to find out what others were doing as I surely can't be the only one using Chromecast. You'all aren't all using Apple are you?

 

[Morris]

I've been using Chromecast on the 384 based Merlin since the early part of this year. I have all IoT devices including phones and tablets on the same guest network. And I agree with you, the guest network should be isolated from the inside network. It has worked like this on the 384 based Merlin since early this year.

The issue is that on the 386 code base, it appears that Asus has broken the guest network. Because if you isolate the guest network from inside network (GUI Setting "Access Intranet" = disabled), you lose the ability to use Chromecast. Setting the variable as I describe earlier appears to preserve the isolation of the guest network from the inside network while also allowing Chromecast to work.

I posted this to share a workaround and also to find out what others were doing as I surely can't be the only one using Chromecast. You'all aren't all using Apple are you?

I'm very happy with my Chrome Cast devices. They are configure as I described. You need to chose where they will be available and wall your network off properly. The history of broken code dose not matter. What matters is hear and now.

Morris

 

[JWoo]

In software, the biggest frustration for customers is finding something that worked in the old release broken in the new release. Simplest way I can put it. Using the 1st 5Ghz Guest Network as an example, with Guest Network on and Intranet Access set to disabled, wl1.1_ap_isolate=0 in the 384 builds and wl1.1_ap_isolate=1 in the new 386 builds. This is what seems to break Chromecast.

 

[Morris]

In software, the biggest frustration for customers is finding something that worked in the old release broken in the new release. Simplest way I can put it. Using the 1st 5Ghz Guest Network as an example, with Guest Network on and Intranet Access set to disabled, wl1.1_ap_isolate=0 in the 384 builds and wl1.1_ap_isolate=1 in the new 386 builds. This is what seems to break Chromecast.

Agree, yet as a Beta Tester, you need to be open minded to the reality of what has happened is you have been taking advantage and have actually been at risk of a bug. That bug has been corrected and you need to adjust.

Morris

 

[thewan]

Logically, Isolation is supposed to not allow ANY communication, even between two isolated networks. If you can communicate with any device, regardless how you communicate, via chromecast in this case, then your network is not isolated anymore and it defeats its purpose in the first place.

Put it this way, you can communicate with your chromecast device, and it can communicate back to your host. If you chromecast device is infected/hacked, it can spread to your other devices through that very same channel that you cast in the first place.

Unless the option to disable Intranet TOTATALLY disables it, as in ZERO communication between devices in isolated networks, it doesn't help to protect your devices from your IOT and only gives you a false sense of security. Asus has fixed the issue and in 386 Disable Intranet is finally working as intended. As Google acknowledged below, you are not supposed to be able to communicate with your chromecast device when you are in a Guest Network. You must disable it.

Learn More: AP Isolation is enabled - Chromecast Help (google.com)

 

[cooloutac]

i also notice the latest firmware makes a different subnet for the guest 1 network. because of this I don't think allowing intranet will make any difference, like bbunge said you need to set it up in guest 2 or 3. I actually like that Asus did this since the isolation was not that great beforehand. But I'm also having the problem others noted in other threads of not being able to specify dns for guest 1. I hope when aimesh 2.0 is released for the ax58u there is an option to do this.

 

[elorimer]

This might be an edge case now for a $20 travel router.

 

[Morris]

i also notice the latest firmware makes a different subnet for the guest 1 network. because of this I don't think allowing intranet will make any difference, like bbunge said you need to set it up in guest 2 or 3. I actually like that Asus did this since the isolation was not that great beforehand. But I'm also having the problem others noted in other threads of not being able to specify dns for guest 1. I hope when aimesh 2.0 is released for the ax58u there is an option to do this.

Subnet? This is an IP V4 and IP V6 feature implying layer 3! Are saying that it uses different subnet masks? This would not provide proper separation for layer 2 protocols. Each SSID should be assigned a VLAN as this is how things are done at layer 2. That is what should be. I don't know what Asus did.

 

[cooloutac]

Subnet? This is an IP V4 and IP V6 feature implying layer 3! Are saying that it uses different subnet masks? This would not provide proper separation for layer 2 protocols. Each SSID should be assigned a VLAN as this is how things are done at layer 2. That is what should be. I don't know what Asus did.

thats what a different subnet is. I don't know what you mean by layers, which is chromecast? have you tried what bbunge suggested? you have to use guest network 2 or 3. Enabling intranet on guest 1 will probably have no effect. also like thwan said it kind of defeats the purpose Unless you are setting a timeout period for the ssid or only allowing intranet temporarily, there is really no point to using the guest network and always allowing intranet.

 

[Morris]

thats what a different subnet is. I don't know what you mean by layers, which is chromecast? have you tried what bbunge suggested? you have to use guest network 2 or 3. Enabling intranet on guest 1 will probably have no effect. also like thwan said it kind of defeats the purpose Unless you are setting a timeout period for the ssid or only allowing intranet temporarily, there is really no point to using the guest network and always allowing intranet.

OSI Network Stack:

OSI model - Wikipedia

en.wikipedia.org

 

[cooloutac]

OSI Network Stack:

OSI model - Wikipedia

en.wikipedia.org

the problem here is protocols though. This first statement in this article might be easier to understand Are Layer 2 or Layer 3 Protocols Better? Yes. - Component (biamp.com) I was asking which category you assume chromecast falls into. As an above poster stated google implies it won't work with a guest network, which is assumed to be isolated. So the question is, is your chromecast routing outside the subnet/lan? I'm assuming it stays within the lan. I use chromecast to my tv but specifically made sure not to put my phone and tv on different vlans. Aka ssid with diff Subnet(which latest firmware does for guest 1) or with intranet disabled. Also make sure ap isolate is not on.

As a different example, i put my echo, ring, blink and nest devices on isolated guest networks because those are accessed through the wan side.