04-25-2022 12:51 AM
Hi.
I have a wireless network that i administrate on a Cisco 9800-CL WLC. This network has the P2P Blocking action set to "Drop" due to security reasons. I want a Google Chromecast on this network. With the current configuration on the WLC i cant even set it up. Because it relies on a connection between a mobile device and the chromecast, which currently are getting dropped, due to the policy.
So my question: Is it possible to continue having the policy set top "drop", and exclude the chromecast device with MAC-adress so that all devices can communicate with the chromecast device and only that, (not other devices on the network). Again this due to security reasons.
I also have a picture attached here that shows other options. "Forward-UpStream" and "Allow Private Group", could one of these be used?
The easy fix is to setup another WLAN / SSID that has "disabled" P2P action. But i was hoping there was a workaround here with an exclusion of some sort.
Any help would be appericiated!
Solved! Go to Solution.
04-26-2022 08:07 AM
Option 2 sounds like the solution used in many hotels which requires a Chromecast proxy server which sits between the networks - it has an interface on each.
Option 1 should be easily done by simply configuring both SSID/WLAN on the same interface. Not sure how the P2P blocking will handle that but it might actually work. Try it out and let us know
04-26-2022 10:46 PM
Option 1 would work only if you map both SSIDs to the same VLAN, this way you will be able to use mDNS for autodiscovery which is one of the advantages of these devices.
Option 2 would definetively work as this is the intent of this setup mode.
04-25-2022 02:23 AM
It depends on the security of that SSID.
You could solve it by using iPSK, if the SSID was using PSK up until now:
Otherwise you need to allow Peer to Peer (like it is typically on wired) communication.
04-25-2022 04:38 AM
P2P is permit all or deny all.
If by any chance the application use some sort of server then you could use "Forward-UpStream"
and "Allow Private Group", relies on iPSK devices.
04-25-2022 06:19 AM - edited 04-25-2022 06:20 AM
As usual the documentation is not great - but as others have hinted the allow-private group options only creates close user groups for users using the same PSK:
"You can also block the peer-to-peer traffic if any two clients do not share the same pre-shared key (PSK). This is supported on local and flex-connect modes.
Peer-to-peer blocking can be configured at three levels: allow, drop, and pre-shared key.
Allow-private-group: Enables the blocking of peer-to-peer traffic with the same tag value. If allow-private-group is disabled, then all peer-to-peer traffic with different tag values are dropped."
But that won't actually do what you want anyway. I think your only way to achieve this will be P2P allowed and with ACLs to control the access but that will probably be far from perfect. Also watch out for how Chromecast loads up the SSID.
04-26-2022 05:05 AM
Hi. You are right. This will not work the way i want it too. I'm not able to use iPSK. As i am unable to tag devices. But i've been looking into another workaround. Which is going have to be to solution here, because, lets face it, it's not possible to do what i want in my current network. Which basically is to: Use the network that i have, that has "Drop" in P2P in WLC. But i want them to not drop to only one device, this chromecast device. I tought this was possible trough some way of MAC-address reservation of some kind. But i guess if it says "Drop" it drops all P2P traffic on the network...
So i have come up with two workarounds. And need to know if option 1 is possible, with someones confirmation.
Option 1: My current network that i have i WLC that is set to "Drop". Lets call this SSID: "Network 1". Can i set up a new SSID "Network 2" on the WLC and put the chromecast / IOT devices etc in this network. And from there configure a bridge betweek network 1 and 2. Because the devices on "Network 1" are the ones that need to "cast" to the chromecast which is on "network 2". If you catch my drift.
Option 2: Create a new SSID for Chomecast / IOT devices and use the chromecast in "Guest Mode" which will prob work as its not reliant to be on the same WiFi as the device that "casts" to the chromecast, but is instead reliant on a PIN (4-digit code) to cast.
@Rich R @Flavio Miranda @patoberli
Let me know if you can think of another workaround.
04-26-2022 05:48 AM
Not sure about option 2. But about option 1, probably wont work. Usually this kind of solution requires that all devices to be on the same network segment and when you create two SSIDs you are creating two networks.
This is about security versus usability. In order to be security, I can´t use our solutions.
04-26-2022 08:07 AM
Option 2 sounds like the solution used in many hotels which requires a Chromecast proxy server which sits between the networks - it has an interface on each.
Option 1 should be easily done by simply configuring both SSID/WLAN on the same interface. Not sure how the P2P blocking will handle that but it might actually work. Try it out and let us know
04-26-2022 10:46 PM
Option 1 would work only if you map both SSIDs to the same VLAN, this way you will be able to use mDNS for autodiscovery which is one of the advantages of these devices.
Option 2 would definetively work as this is the intent of this setup mode.
04-27-2022 06:05 AM
Brilliant. Thanks for the responses: @JPavonM @Rich R @Flavio Miranda . I'm going to go for option 2 as this is what its intended for. Due to security reasons, i'm not able try option 1, i cannot have the SSID's in the same VLAN. As much as i would like to try it. This is in a production enviroment, if it would have been a lab, i woudl've tried it. Maybe sometime in the future.
- Kristian
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide