Wireless Access

Having an issue with users being dropped from the network with "Reason Ptk Challenge Failed"    The controllers are running 6.3.0.1.

I just started looking into it, but it looks to be MacOS systems.  

I saw one post with this message referencing the IP Spoofing issue of 6.2.   It does not appear to be the same thing; but I could be wrong.  

Is "Validate PMKID" and "Oportunistic Key Caching" enabled in the 802.1x profile?

In the advanced settings for the firewall, is "prohibit IP spoofing" on or off?

EDIT:

That location's profile has Validate PMKID enabled and Opportunistic Key Caching disabled.       I am going to compare with the other profiles that are setup.

Prohibit IP Spoofing is "enabled" for IPv4; disabled for IPv6 (as is all IPv6)

I'll uncheck it from IPv4 Seth.  What is the recommended settings for OKC and Validate PKMD in this type of setup (primarily Macs)?  Both are disabled.

In the 802.1x auth profile (under the AAA profile), ONLY check off "Validate PMKID".  Leave OKC unchecked

---

@clembo wrote:

I'll uncheck it from IPv4 Seth.  What is the recommended settings for OKC and Validate PKMD in this type of setup (primarily Macs)?  Both are disabled.

---

Clembo,

OKC is on by default and many Windows clients leverage this.  If OKC was turned off, I would check to see if anything else is changed in that profile because it is on by default.  Ideally in a mixed environment you would have OKC on and Validate PMKID on, as well.

Supporting facts:

OKC or opportunistic key caching is a mechanism that allows devices to NOT have to re-negotiate keys with a radius server when roaming from one access point to another AP that they have already been on.  Devices that support OKC enjoy faster roam times to access points to which they have previously associated.  This ONLY applies on a 802.1x WLAN.

Sethfiermonti,

I don't have any supporting facts quotes.

We do have a University in New England where that specific message was showing up both on the controller and on the MAC OSX client when the debugging was turned on.  OKC was off at the time.  We turned on OKC AND Validate PMKID, and clients that leveraged OKC as well as MACs had a better experience and we never saw that message again.

They know who they are and can chime in here.

Not disagreeing...just presenting the knowledge and will let others decide.  Always good to know that those checkboxes are doing :)

for what it's worth.   Since disabling the firewall spoofing setting (IPv4), the Ptk Challenge Failed message has not been seen.  The profile still has both OKC and Validate PKMID disabled.  

The environment is probably 80-85% Mac and/or iOS.  

I know what the settings do, but is their harm in disabling both.....or is it better to eneable both?

I know this is an old thread, I just wanted to say thanks as this article came in handy. A new install was left with PMKID set to disabled when the default option by the system is enabled. No other changes were needed to be made for OSX to roam correctly.

Thanks,

Justin

Hi,

We have this problems "Ptk Challenge Failed" with an iPhone 6 with iOS 9.0 and Aruba controller 6.4.2.7.

It is the first iOS 9 have in our network, Will we have problems with the new version?

We have tried without succes:

• Checked OKC and Validate PMKID, failed
• Uncheck OKC and Validate PMKID, failed
• Uncheck Prohibit IP Spoofing (just in case, the device has no IP and fails in 4-way handshake), failed
• Enable 802.11r , failed (we have disabled 802.11r for compatibility reasons)

Any suggestions?

Best regards,

Toni

toni, that's interesting.  What does it look like from the iOS9 client side -- does the client just fail entirely or does it connect and then get kicked off a lot?

The issue is with iOS9 and ClearPass 6.5.1. The same SSID config with Freeradius works fine.

May be a problem with PMK distribution?

ClearPass enforcement is ok with controller role with accept.

What parameters can be modified in ClearPass for this issue?

toni.perez,

IOS9 is prerelease software and your issue should be reported to Apple so that it can be fixed in release code.  If it worked in IOS8 but does not work in IOS9, this is something Apple should fix based on your feedback, because they possibly changed something.

Sorry to resurrect this thread again but we seem to be encountering this issue on 6.4.2.12. We opened a TAC case and they directed us to this post and recommended that we turn off the IP spoofing (we are having problems with a PSK SSID so OKC should not be the problem).

Our question is "why"? IP spoofing should have nothing to do with the symptoms of the problem. We are going to disable it in our next MW but it doesn't explain what is causing the problem.

FYI in the auth-tracebuf we see that when things are working, the 4 WPA keys get exchanged, and when it doesn't work, the AP sends key 1 three times then drops the station. No MIC failures. Affected clients are MAC OS X Yosemite (10.5).

Thanks cjoseph,

There is definitely some higher contention at this office which we are taking steps to mitigate. However in the meantime would think increasing the number of retries and/or timers could help, assuming disabling IP spoofing does not help?

Tim

We actually did ask our engineer why we should disable IP spoofing, and he directed us to this thread. I argued with him by saying that this thread does not explain "why" IP spoofing would cause this problem but he wouldn't give any explanation beyond that. I'll make sure we press again next time we follow up on the case.

So, looking back at this thread, there was a bug two years ago that involved turning on ip spoofing triggering something that resembled this issue.  Assuming that you have upgraded between then and now, it probably would not apply to you.  TAC frequently takes precautions to simplify things and to remove them as possible issues.  It would be unlikely, but plausible to do what they did in this case.