Mauricio Parra wrote:
I had the same problem and using this post I also find the solution and the explanation...
Configure the EAP Payload Size
Configure the Framed-MTU Attribute
Thanks for this, saved me a world of hurt, almost rebuilt my NPS and CA.
Chaning the Framed-MTU to 1344 is the answer.
We spent many hours trying to solve this problem.
Cisco wireless setup, using windows NPS for 802.1x authentication.
Certificate base auth, with an internal PKI sending out client machine certs, and also the server cert.
Auth was failing with "reason code 22, The client could not be authenticated because the Extensible Authentication Protocol (EAP) Type cannot be processed by the server."
It turned out to be a GPO setting on the server, that was enforcing key protection.
There is this note on the below technet article:
Requiring the use of strong private key protection and user prompting on all new and imported keys will disable some applications, such as Encrypting File System (EFS) and wireless (802.1X) authentication that cannot display UI. For more information, see article 320828 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=115037).
Hopefully this helps someone out, if you have the same annoying error.
I realize this is a little dated, but I wanted to let everyone know that I had these same errors/issues and we were able to correct it by updating the server certificate on the NPS server.
We recently saw something similar to this. Our Cisco WLC showed a message like this:
|Thu Sep 24 15:16:54 2015|
RADIUS server 220.127.116.11:1812 failed to respond to request (ID 217) for client f8:95:c7:a6:34:7c / user 'f8-95-c7-a6-34-7c'
We found the LG Phones were sending an illegal EAP code of 53 which was being silently ignored by our authentication server. According to RFC3748 the WLC should also drop this and not pass it to the authenticator in the first place.
Because the Auth server was silently ignoring the request, the WLC thought the auth server was dead and tried to switch to another one. The the WLC keeps flipping between auth servers, which also cuts off other client authentications that are in progress. This actually causes queuing issues on the auth server as well because it is waiting on the requests that got cut off by the WLC switching to another auth server.
Right now we are Blacklisting the MAC's of these phones as a workaround. We need a more permanent solution of course. It may be a while before the WLC follows the RFC and discards EAP frames with illegal codes.
The WLC is only forwarding the packet and not inspecting it prior to sending it to the radius server. It unfortunately has no way to tell if the packet contains an invalid EAP type. Depending on your radius server, if you can posture you can possibly make a rule that has the radius server reply to the WLC with a "deny" even though this does not follow the RFC. You can then create a rule to automatically blacklist a device after X amount of unsuccessful login authentication attempts. Not the best solution but depending on your radius server it will automate the process of blacklisting those devices and end the issue with the DoS you have occurring with the timeouts.
For me, I got the same message but the situation is not the same.
I follow the below doc to setup NPS.
In the above step, it said certificate could not found. If you ignore it, you will also get the same message.
Reason-Code = 22
Reason = The client could not be authenticated because the Extensible Authentication Protocol (EAP) Type cannot be processed by the server.
After I import a computer certificate to my NPS, it works.