ExtremeWireless 10.11.03.0004- 802.1x EAP-TLS auth failed

[LeoP1]

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

[Joseph_Burnswor]

Have we tried going to 10.11.04?

[LeoP1]

Greetings,

We are running a further investigation...

Maybe the KB wasn't the only problem.

I'll keep you informed about our progress to try to really pinpoint the root cause.

Best regards,

-Leo

[LeoP1]

Greetings Pala and Jeremy,

Following up with the issue, the customer called me telling the Cisco solution suddenly stopped working too...

Some suspects have arisen about the MS KB3199173 and the customer decided to uninstall it and voialà... Everything come back to life!

Both Cisco and Extreme wireless solutions are operational without touching anything in the configs, just uninstalling the KB from the PC clients.

MS messed up with something in this update. The customer started a WSUS operation to mass-uninstall this KB from all PCs in the infrastructure.

Maybe someone from the Wireless Engineering/PM should take a look at it to avoid issues with other customers and maybe inform the GTAC team about our findings.

Thank you for your help!

Best regards,

-Leo

[Jeremy_Gibbs]

Have you verified that the server and client certs are all valid. Also, make sure the data / time is correct on the RADIUS server. I have seen time drift cause this error before. I suggest using a NTP server for everything (just making some suggestions).

Also, check to make sure EAP-MSCHAPv2 is selected for your authentication methods ...

[Zdeněk_Pala]

Hi Leo. The controller/AP is only encapsulating/decapsulating the traffic from EAPoL to EAP in the radius protocol. If there is wrong eap type it is on the client or on the radius server. I would focus to client/radius server troubleshooting. You may check the wireshark capture what eap is being sent by the client... Good luck! Z.