Wireless Access

Good Day All,

I have 3 IAP clusters at multiple locations, I am trying to figure out why 802.1x authentication is failing at 2 sites, but working perfectly fine at the other.

I have setup a manual network profile in GPO, which is taking effect and seems to allow the client computer to connect. However, upon connected, the AP immediately dissociates the client and the connection fails.

We are using certificate based machine authentication which works at one site, but not the others. The APs are currently set up with WPA2 and WPA2-Ent networks, so we know that there is at least some level of connectivity since the local DC is also handing out DHCP leases (And does so occasionally to RADIUS clients).

Our organization has been having this issue for weeks, and numerous configuration changes keep yielding the same results.

Any suggestions from anyone? I already have a support request open and have done tech support dump, and packet capture, but this has only cemented the root cause of the problem--it hasn't led to any workable fix as of yet.

Did you setup the proper RADIUS clients and Network policies on NPS?   Perhaps the NPS policy is unique to the one working cluster?

Can you share the event log from the NPS server for a failed connection?   

The policies are the exact same on all of the NPS servers.

The connections aren't failing either, they all come back as access granted--but then the AP is dropping the response.

Check the auth-trace debug logs on the IAP and report what you are finding for that MAC Address.

http://community.arubanetworks.com/t5/Command-of-the-Day/COTD-Instant-show-ap-debug-auth-trace-buf/idi-p/188766

Sep 22 12:00:59  eap-id-req            <-  10:4a:7d:db:d8:a0  94:b4:0f:e6:f9:a4                 7    5  

Sep 22 12:01:04  deauth        94:b4:0f:e6:f9:a4  10:4a:7d:db:d8:a0  94:b4:0f:e6:f9:a4  15      Denied; Ageout (seq num 3211)

Sep 22 11:59:02  assoc-resp    94:b4:0f:e6:f9:a4  10:4a:7d:db:d8:a0  94:b4:0f:e6:f9:a4  15      Success

Sep 22 11:59:02  assoc-req     10:4a:7d:db:d8:a0  94:b4:0f:e6:f9:a4  94:b4:0f:e6:f9:a4  60      -

Sep 22 11:59:02  auth          94:b4:0f:e6:f9:a4  10:4a:7d:db:d8:a0  94:b4:0f:e6:f9:a4  15      Success (seq num 0)

Sep 22 11:59:02  auth          10:4a:7d:db:d8:a0  94:b4:0f:e6:f9:a4  94:b4:0f:e6:f9:a4  0       -

Sep 22 11:55:46  deauth        94:b4:0f:e6:f9:a4  10:4a:7d:db:d8:a0  94:b4:0f:e6:f9:a4  15      Denied; Ageout (seq num 3211)

Sep 22 11:53:55  assoc-resp    94:b4:0f:e6:f9:a4  10:4a:7d:db:d8:a0  94:b4:0f:e6:f9:a4  15      Success

Sep 22 11:53:55  assoc-req     10:4a:7d:db:d8:a0  94:b4:0f:e6:f9:a4  94:b4:0f:e6:f9:a4  60      -

Sep 22 11:53:55  auth          94:b4:0f:e6:f9:a4  10:4a:7d:db:d8:a0  94:b4:0f:e6:f9:a4  15      Success (seq num 0)

Sep 22 11:53:55  auth          10:4a:7d:db:d8:a0  94:b4:0f:e6:f9:a4  94:b4:0f:e6:f9:a4  0       -

<132197> <ERRS> |AP 94:b4:0f:c6:6f:9a@10.6.26.22 stm|  Maximum number of retries was attempted for station host/***************** 10:4a:7d:db:d8:a0 94:b4:0f:e6:f9:a4, deauthenticating the station

I figured this one out.

The issue was being caused by DRP nad misconfigured switches from our vendor.

Some packets were arriving with 802.1q headers and others were not. Our core switches were configured not to use vlans, while our access switches were configured to use tagging. This caused DRP to become 'confused' and think that the packets were malformed thus, it would drop the responses.

I hope this helps someone else out there.