Cloud Managed Networks

 View Only

  • 1.  Issues with Host Blocking on Guest-SSID using Captive-Portal

    Posted Oct 20, 2025 05:19 PM

    Hi

    We have a Wi-Fi deployment that using a Tunneled-SSID architecture.

    • Guest-SSID is tunneled to a Guest-VLAN (500), back to an Aruba 9114 GW in our Datacenter.
    • VLAN500 is the Guest-WiFi VLAN that is used for all general internet traffic.
    • SSID Authentication is PSK; after the user authenticates, they will get redirected to the default Aruba Cloud-Guest captive-portal, which then the user "Accepts", and is given access to internet.

    Our issue is we have a few clients / devices that we want to "block", but we are unable to do so.

    • After going to the AP Group> Clients> Find the device> Actions> Block Client, the device's MAC is put on this "Denylist", but even so, the user is still connected.  The client does not even get disconnected.
    • The only thing that works is disabling the AP, which is not ideal as it affects all other clients.
    • When I do the above to a device connected on an SSID that does not use captive-portal, (It's using PSK only) the block works. 
    • So the "block client" action only works for SSID's that are not using the captive-portal.

    Our SSID config is as follows:

    • Security Level: Visitors
      • Cloud Guest (Aruba Captive-Portal)
    • Access Rules
      • Unrestricted
      • Not using role or network based access
    • Not using Clearpass or any equivalent products for our wireless networks.

    Any idea or help is greatly appreciated.

    Regards,

    VC



    -------------------------------------------


  • 2.  RE: Issues with Host Blocking on Guest-SSID using Captive-Portal

    Posted Oct 21, 2025 10:38 AM

    Blocking the client results in the AP adding the client to a denylist. The AAA configuration for Cloud Guest would then have to be configured to use the denylist which doesn't appear to be an option.



    ------------------------------
    Carson Hulcher, ACEX#110
    ------------------------------



  • 3.  RE: Issues with Host Blocking on Guest-SSID using Captive-Portal

    Posted Nov 19, 2025 05:19 AM

    When you add a client's MAC address to the denylist, the device may still connect because it uses a random (private) MAC address each time it tries to join the SSID. To block the device properly, the user must first disable the "Random MAC" or "Private MAC" feature on their mobile or other device. After they disable it, the device will use a fixed MAC address. Once the MAC address becomes permanent, you can add that MAC address to the denylist and it will no longer change. Only then will the denylist work correctly.

    -------------------------------------------



  • 4.  RE: Issues with Host Blocking on Guest-SSID using Captive-Portal

    Posted Nov 19, 2025 12:00 PM

    I'm not sure about your technical issue but pragmatically, denylisting is no longer a viable function in WiFi networks. This isn't an Aruba-specific issue-it's a broader WiFi limitation. In the past, most users didn't know how to change their MAC addresses, so denylisting was somewhat effective. However, more advanced users could easily modify their MAC address to bypass the block, meaning it was never a strong security control.

    More recently, advertisers and data collection companies began indexing SSIDs globally, using wireless MAC settings to track user activity. In response, Apple began enabling MAC address randomization by default on iOS devices to prevent advertisers and trackers from following users across WiFi networks. The goal was to stop passive tracking of devices through their fixed hardware MAC addresses, which could otherwise reveal location history and usage patterns. Google and later Microsoft implemented similar randomization features, making it a sudo cross-platform standard on most modern devices-especially mobile device.  Now the majority if connections to WiFi networks use a different randomized MAC address each time. This makes MAC blocklisting an ineffective technique for managing guest access.  So unless you have administrative access to the device you are trying to block to disable randomization; even if you did block it,  the block would only be temporary anyway until their device reset the mac address the next time it connected.

     




    Original Message


Related Content