11-15-2018 05:46 AM
Two SSIDs being broadcast at a location.
One is 802.11x Corporate SSID (let us call it A) the other is Guest SSID (let us call it B).
SSID A is defined by GPO/policy, every device will have it.
Users are able to add the Guest SSID (B) on their own.
Since both these SSIDs are being broadcast and visible to the clients at the same signal strength, will the clients not run into issues and could flap between the two SSIDs ?
I am recommending, if you add the Guest SSID B, remove it after use or better still we should have policy/GPO on Windows, Chromebook and MacBooks that do not allow a users to add the Guest SSID.
I know there are options on devices to set priority, auto connect, prefer network etc. but these appear to have unpredictable outcomes.
Do my above recommendation make sense ?
Solved! Go to Solution.
11-15-2018 05:52 AM
Add the GUEST SSID with a WPA2-PSK, so that users cannot successfully connect to it for company-owned devices.
Typically a device will not flap between two SSIDs if both are added, but you don't want to have to troubleshoot corporate devices that have accidentally connected to the guest SSID.
*Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba Networks or Hewlett Packard Enterprise.*
ArubaOS 8.4 User Guide
InstantOS 8.3 User Guide
Airheads Learning Videos
Aruba Central Documentation
Sign up for Security Alerts
Aruba Technical Webinars
Re: Flapping between Corporate and Guest SSID.
11-15-2018 06:32 AM
Device prioritize network connections, so you would just need to make sure Corp SSID is a higher priority then Guest.
I would do something like mentioned before if you want to prevent them from connecting all together.
If my answer is helpful, a Kudos is always appreciated!
11-17-2018 10:36 AM
I have not found a good solution for Macs. We’ve tried adding the open guest ssid with an invalid PSK but somehow machines are still ending up connected to the guest network, which ends up causing support tickets about connectivity issues.