Wireless Access

We created a new SSID that authenticates smartphones/tablets with a cert issues from a MobileIron appliance.  Authentication is working great, however connectivity sporadically drops every minute or two and takes another 30 seconds or so to reauthenticate. 

Scouring the Internet for information and it appears there are a few issues to juggle with BYOD:

1. To conserve battery life, some manufacturers cause wireless NIC's to go dormant when data isn't being transmitted.  A potential fix for this is to shorten beacon time from 60 seconds to 10 seconds so the device never have a chance to go dormant. 

2. EAP/TLS appears to be a beefy authentication mechanism and does not reauthenticate very quickly.  When an adjacent AP proves to be a more attractive option to a particular smart device, the smart device migrates to it.  In our exprience that switch is not seemless, and because we're using cert authentication, the reauthentication on the new AP takes awhile. 

 

For argument sake we tested smart devices on an SSID that authenticates with EAP-PEAP/AD Creds and it is seemless. You can roam all day long and never drop a ping.  

So my question is, has anyone implemented a BYOD solution comprised of an SSID with EAP-TLS authentication and MobileIron as the MDM in the background?  If so, what tweaks did you have to make to ensure stability?  802.11k?  Beacon timers?  

We can't be the only company out there that has mobile devices, MobileIron and Aruba wireless.  Curious as to everyone else's experience. Thanks!

 

1.  Troubleshoot a single client or client-type at a time

2.  Configure user-debuging for that client or for only a few clients at a time.  Use "config t  logging level debugging user-debug <mac address of device>"

3.  Try to replicate the situation, then type "show auth-tracebuf mac <mac address of device>" to understand where the slowdown is happening

4.  To remove a user from debug use "config t no logging level debugging user-debug <mac address of user>"

5.  To see what users are being debugged, type "show debug"

 

 

Thanks Colin.  I'll test and update. 

I don't have a baseline for a proper EAP-TLS transaction, but after debugging I get the following continual output :

 

Dec 11 10:57:13 station-down * 18:f6:43:b8:fc:9e 24:de:c6:df:5b:24 - -
Dec 11 10:57:14 station-up * 18:f6:43:b8:fc:9e 24:de:c6:df:5b:24 - - wpa2 aes
Dec 11 10:57:14 station-term-start * 18:f6:43:b8:fc:9e 24:de:c6:df:5b:24 40 -
Dec 11 10:57:14 client-cert -> 18:f6:43:b8:fc:9e 24:de:c6:df:5b:24/Ventas-Mobile-WiFI 1199 1199
Dec 11 10:57:14 client-cert verified * 18:f6:43:b8:fc:9e 24:de:c6:df:5b:24 - -
Dec 11 10:57:14 cert-signature-verify -> 18:f6:43:b8:fc:9e 24:de:c6:df:5b:24/Ventas-Mobile-WiFI - - verified
Dec 11 10:57:14 client-finish -> 18:f6:43:b8:fc:9e 24:de:c6:df:5b:24/Ventas-Mobile-WiFI - -
Dec 11 10:57:14 server-finish <- 18:f6:43:b8:fc:9e 24:de:c6:df:5b:24/Ventas-Mobile-WiFI - 61
Dec 11 10:57:14 server-finish-ack -> 18:f6:43:b8:fc:9e 24:de:c6:df:5b:24/Ventas-Mobile-WiFI - -
Dec 11 10:57:14 eap-success <- 18:f6:43:b8:fc:9e 24:de:c6:df:5b:24/Ventas-Mobile-WiFI - 4
Dec 11 10:57:14 wpa2-key1 <- 18:f6:43:b8:fc:9e 24:de:c6:df:5b:24 - 117
Dec 11 10:57:14 wpa2-key2 -> 18:f6:43:b8:fc:9e 24:de:c6:df:5b:24 - 117
Dec 11 10:57:14 wpa2-key3 <- 18:f6:43:b8:fc:9e 24:de:c6:df:5b:24 - 151
Dec 11 10:57:14 wpa2-key4 -> 18:f6:43:b8:fc:9e 24:de:c6:df:5b:24 - 95

 

Looks like the WPA2 key exchange is the culprit and the certificate authentication, but not sure how that is supposed to play out with my configuration.  What are these 4 x WPA2 keys it's looking for? 

 

 

Here's a screenshot of the output for easier reading:

That looks fine.  So the only thing of note is that you are doing termination on the controller.  What are your settings there in the 802.1x profile?

 

For what its worth, here is the 802.1x L2 Auth profile:

 

I think I figured out the issue.  I have a policy blocking everything internal, with the exception of DHCP, DNS and a few internal resources that we want to allow.  After removing this policy from the Mobile WiFi role it's stable.  So I'm going to have to figure out what else it needs open, in addition to the basics, to maintain connectivity. Thanks!

That authentication looks good. Looks like you're using EAP termination. Are you doing OCSP certificate checks?

Sent from Nine

Nope.  No OCSP.  This is all brand new with certs not expiring for 3 years. 

Just an FYI...to fix this issue I removed an ACL prohibiting mobile users from coming inside to local resources.  In the ACL I allowed DHCP, DNS and ClearPass (guest sponsorship approval), but everything else was denied. Not sure what else I  need to allow, but for now removing the ACL was the winner.  I will eventually reapply the ACL and slowly tighten it up, but for now it's off.  Mobile users get Google DNS, so they couldn't resolve internally anyways.  Thinking I may have allow the controller's IP in the ACL for the cert piece. 

Depending on your mobile device vendor, you may be running into something like Samsung's Auto Network Switch.  If the device decides that the wireless network isn't "good enough", it will decide on it's own to disconnect.  If your ACL is blocking any of the traffic that the device is using to test connectivity, you might be tripping the auto disconnect.