Controller Based WLANs

Why am I unable to pass traffic after successfully authenticating via dot1x when LMS is local, but I can pass traffic when LMS is the master?

Product and Software: This article applies to Aruba M3/3000 series controllers running ArubaOS 3.2 or later.

When a new M3/3000 series controller is turned on as a local controller, wireless users might be able to connect but not be able to get an IP address nor pass any traffic even though dot1x authentication is successful and key exchange passed.


This sample output shows that everything is ok, but the user was not able to pass traffic.

Sep 2 14:24:15 eap-req           <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22                       15 1031
Sep 2 14:24:15 eap-resp          -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22                       15 200
Sep 2 14:24:15 rad-req           -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22/test 76 379
Sep 2 14:24:15 rad-resp          <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22/test 76 124
Sep 2 14:24:15 eap-req           <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22                       16 53
Sep 2 14:24:15 eap-resp          -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22                       16 6
Sep 2 14:24:15 rad-req           -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22/test 77 185
Sep 2 14:24:15 rad-resp          <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22/test 77 99
Sep 2 14:24:15 eap-req           <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22                       17 28
Sep 2 14:24:15 eap-resp          -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22                       17 47
Sep 2 14:24:15 rad-req           -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22/test 78 226
Sep 2 14:24:15 rad-resp          <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22/test 78 124
Sep 2 14:24:15 eap-req           <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22                       18 53
Sep 2 14:24:15 eap-resp          -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22                       18 101
Sep 2 14:24:15 rad-req           -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22/test 79 280
Sep 2 14:24:15 rad-resp          <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22/test 79 145
Sep 2 14:24:15 eap-req           <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22                       19 74
Sep 2 14:24:15 eap-resp          -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22                       19 29
Sep 2 14:24:15 rad-req           -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22/test 80 208
Sep 2 14:24:15 rad-resp          <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22/test 80 109
Sep 2 14:24:15 eap-req           <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22                       20 38
Sep 2 14:24:15 eap-resp          -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22                       20 38
Sep 2 14:24:15 rad-req           -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22/test 81 217
Sep 2 14:24:15 rad-accept        <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22/test 81 263
Sep 2 14:24:15 eap-success       <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22                       21 4
Sep 2 14:24:15 station-data-ready * de:ad:be:ef:ca:fe 00:00:00:00:00:00                       50 -
Sep 2 14:24:15 wpa2-key1          <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22                      - 117
Sep 2 14:24:15 wpa2-key2          -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22                      - 119
Sep 2 14:24:15 wpa2-key3          <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22                      - 167
Sep 2 14:24:15 wpa2-key4          -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22                      - 95



The 'show datapath crypto' command reveals a large number of decryption failures (AES or TKIP, depends on the configuration):


ArubaM3K1) #show datapath crypto counters

Datapath Crypto Statistics
--------------------------
Crypto Accelerator         Present
Crypto Cores In Use        4
Crypto Cores Total         4
Crypto Requests Total      143949
Crypto Requests Queued     0
Crypto Requests Failed     0
Crypto Timeouts            0
IPSec Encryption Failures  0
IPSec Decryption Failures  0
IPSec Decryption Loops     0
IPSec Decryption BufFail   0
IPSec Decr SPI(client) ERR 0
IPSec Decrypt SA Not Ready 0
PPTP Encryption Failures   0
PPTP Decryption Failures   0
WEP Encryption Failures    0
WEP Decryption Failures    0
WEP No Key (not serious)   0
TKIP Encryption Failures   32
TKIP Decryption Failures   0
TKIP Decrypt Bad Counter   0
TKIP P1Key Not Ready       32
TKIP Serialized            24
TKIP Drops                 0
AESCCM Encryption Failures 2
AESCCM Decryption Failures 1667 <<<<<<<<<<<<<<<<
AESCCM Serialized          2
AESCCM Drops               0
AESCCM Decrypt Bad Counter 0
WEP CRC Entries Used       0
WEP CRC Alloc Failures     0
WEP CRC Sending            0
WEP CRC Sent               0
WEP CRC Bad Send           0
WEP CRC Unknown            0
Max Crypto HW Queues       0
Crypto HW Queues Used      0
Crypto HW Queue Alloc Fail 0
XSEC Encryption Failures   0
XSEC Decryption Failures   0
DOT1X Term Buffers         2048
DOT1X Term Buffers Free    2048
DOT1X Term Failures        0
DOT1X Term NAKs            0
DOT1X Term Resends         0
DOT1X Term Succeeded       0


The 'show datapath station' command also shows a large number of decryption failures:


(ArubaM3K1) # show datapath station

Datapath Station Table Statistics
---------------------------------
Current Entries       1
Pending Deletes       0
High Water Mark       2
Maximum Entries       16383
Total Entries         83
Allocation Failures   0
Max link length       1

Datapath Station Table Entries
------------------------------

Flags: W - WEP, T - TKIP, A - AESCCM, M - WMM
       P- Powersave, S - AMSDU

       MAC              BSSID       VLAN Bad Decrypts Cpu Qsz         Flags
----------------- ----------------- ---- ------------ --- ----------- -----
DE:AD:BE:EF:CA:FE 00:0B:86:11:22:33  50      207      16   16161616 A


The problem remains even when the IP address is statically configured and static ARP entry is set up on the wireless client.

However, if you change the SSID to opensystem, then the wireless client is able to pass traffic.

If this happens, verify the following conditions:

  • The local controller is an M3 or 3000 series controller.
  • The AP is locally connected to the master controller and the master controller is the default gateway of the AP.
  • The LMS of the AP is the switch IP of the local controller and it is not on the same IP subnet of the AP.

If these three conditions are true, then these things might have happened:

  • The AP is connecting to LMS. The LMS is not on the same subnet, so the AP sends a packet to its default gateway, which is the master controller.
  • The master controller could only reach the LMS by using IPsec tunnel due to the master-local topology.
  • The master controller sends the AP packet into the tunnel. If the traffic is controller traffic (for example, heartbeat or config push), there is no problem. However if the traffic is user-encrypted traffic, then the packet cannot be decrypted when it reaches the local controller.

This behavior is expected. To correct this problem, change the LMS IP to an IP address other than the switchip of the local controller (for example, a physically interface IP or a VRRP IP).

Version history
Revision #:
1 of 1
Last update:
‎07-05-2014 02:55 AM
Updated by:
 
Labels (1)
Contributors
Search Airheads
Showing results for 
Search instead for 
Did you mean: 
Is this a frequent problem?

Request an official Aruba knowledge base article to be written by our experts.