cancel
Showing results for 
Search instead for 
Did you mean: 

ExtremeWireless 10.11.03.0004- 802.1x EAP-TLS auth failed

ExtremeWireless 10.11.03.0004- 802.1x EAP-TLS auth failed

LeoP1
Contributor
Greetings,
I have a customer running a PoC and now we have problems with the 802.1x EAP-TLS authentication since yesterday.

No workstation is able to authenticate on a 802.1x VNS, while the legacy Cisco solution still working fine. All workstations use EAP-TLS for authentication (certificate installed).

Maybe it's related to the new Microsoft Update (https://support.microsoft.com/en-us/kb/3199173) they deployed yesterday?

The customer is running EW 10.11.03.0004.

The NPS logs show information like this:
Logging Results:
Accounting information was written to the local log file.
Reason Code: 22
Reason: The client could not be authenticated because the Extensible Authentication Protocol (EAP) Type cannot be processed by the server.
Running some sniffing, we got something interesting:
  1. The user tries to connect to the network and the EW send an Access-Request to the NPS
  2. The NPS answer with a Access-Challenge. Inside the packet, there's an EAP-Message(79) indicating the type as "TLS EAP (EAP-TLS) (13)"
  3. The EW send another Access-Request with an EAP-Message (79) containing: "Type Legacy Nak (Response Only) (3)" and "Desired Auth Type: Protected EAP (EAP-PEAP) (25)".
  4. The NPS send an Access-Reject message with "Code: Failure (4)"
It seems that the EW wants to use EAP-PEAP instead of the EAP-TLS (expected by the NPS Server and was working until yesterday).

This makes sense? The customer is trying our solution to replace the existing Cisco infrastructure, but now we are in trouble.

We asked GTAC, but there's nothing reported until now.

Any ideas? Maybe something needs to be fixed on a new FW release?

Best regards,

-Leo
9 REPLIES 9

LeoP1
Contributor
Greetings guys,

After a further investigation with the customer we found the issue.

After the MS KB something changed in the Windows EAP process. Taking a closer look at the NPS the customer added the PEAP method to the rule and now it works.

Before the installation of the KB they only used the "Smartcard or certificate" method on the NPS rule.

Maybe in other scenarios the customers already had Cert + PEAP configured on the NPS and will not be affected, but in this case the config adjustments in NPS solved the problem.

It's cool to keep the community aware of this "new" issue and take a look at the NPS configs.

Thanks for your help!

Best regards,

-Leo

It was very nice to meet you too! Thanks for your support! 

Drew_C
Valued Contributor III
Hi Leo, it was great meeting you at the partner summit a few weeks ago. Thanks for coming back to the community and helping everyone to be aware of this issue!

Jeremy_Gibbs
Contributor
Keep us posted.
GTM-P2G8KFN