Why do few wireless clients experience problem in connecting to an SSID, where other clients have no issue?

By Arunkumar posted Jun 26, 2014 08:12 PM


Environment : This article applies to Aruba Mobility Domain with ArubaOS.


Surprisingly, some clients experience problem in connecting to an SSID and as a WLAN administrator one would not have a clue. The first place where an administrator should look into,  is the output of following CLI command to see if the MAC address of the client is listed here:

"Show ap blacklist-clients"





There are several reasons why a client gets blacklisted. For example, when you enable different Aruba intrusion detection system (IDS) features that detect suspicious activities, such as MAC address spoofing or DoS attacks.

Below shown are the various reasons for a client getting blacklisted:



user-defined: User was blacklisted due to blacklist criteria were defined by the network administrator
mitm-attack: Blacklisted for a man in the middle (MITM) attack; impersonating a valid enterprise AP.
ping-flood: Blacklisted for a ping flood attack.
session-flood: Blacklisted for a session flood attack.
syn-flood: Blacklisted for a syn flood attack
session-blacklist: User session was blacklisted
IP spoofing: Blacklisted for sending messages using the IP address of a trusted client.
ESI-blacklist: An external virus detection or intrusion detection application or appliance blacklisted the client.
CP-flood: Blacklisting for flooding with fake AP beacons.
UNKNOWN: Blacklist reason unknown.


  • You can configure the duration that clients are blacklisted on a per-SSID basis via the virtual AP profile. There are two different blacklist duration settings:

    • For clients that are blacklisted due to authentication failure. By default, this is set to 0 (the client is blacklisted indefinitely)


    • For clients that are blacklisted due to other reasons, including manual blacklisting. By default, this is set to 3600 seconds (one hour). You can set this to 0 to blacklist clients indefinitely.



Aug 15, 2014 04:01 PM

Hi Sean,


The blacklist option on Virtual-AP Profile is enabled by default. The options under Firewall depend on customer environment (example :: TCP sessions for one customer maybe high at value X while it maybe acceptable for another). Hence; this option is disabled by default. It can potentially blacklisted all clients if misconfigured to a low value.


To validate blacklisting based on session; we can troubleshoot using "show datapath user" (shows # of sessions) & "show datapath session table <user ip> . Compare it against the configured value.


Logs would also show entry for it.


May 29 15:45:44  authmgr[3493]: <124006> <WARN> |authmgr|  {638} TCP srcip= srcport=53789 dstip= dstport=3268, action=blacklist, policy=Monitor IP sessions attack
May 29 15:46:07  authmgr[3493]: <124006> <WARN> |authmgr|  {639} UDP srcip= srcport=46934 dstip= dstport=38022, action=blacklist, policy=Monitor IP sessions attack
May 29 15:46:12  authmgr[3493]: <124006> <WARN> |authmgr|  {640} TCP srcip= srcport=39876 dstip= dstport=80, action=blacklist, policy=Monitor IP sessions attack
May 29 15:46:32  authmgr[3493]: <124006> <WARN> |authmgr|  {641} UDP srcip= srcport=50344 dstip= dstport=53, action=blacklist, policy=Monitor IP sessions attack


As a general recommendation; any option should be enabled / configured after thorough evaluation.


Hope this helps.







Aug 15, 2014 01:17 PM

Actually, per our SE these features do not work as advertized and are now disabled by default.  From my personal experience, if they are enabled every client in the system eventually gets blacklisted regardless of the threshold settings.  Do not enable these features.