ACS 5.1 Failure: 5411 EAP session timed out -- Wired 802.1X, machine-authentication

[m.leissle]

Hi guys,

I have a strange error here and I`m really disappointed.

We currently try to do "Wired-802.1X" with our Windows XP SP3 Clients with EAP-TLS and "machine-only" authentication.

We use ACS5.1 to authenticate the clients. At about 50% of the clients authentication works fine.

At the other clients we can see a strange error at the ACS.

At the Reports page --> "Authentications - RADIUS - Today" we see that a client is trying to authenticate, but this fails with the Failure Code: 5411 EAP session timed out.

Logged At	RADIUS Status	NAS Failure	Details	Username	MAC/IP Address	Access Service	Authentication Method	Network Device	NAS IP Address	NAS Port ID	CTS Security Group	ACS Instance	Failure  Reason
Sep 2,10 3:37:46.916 PM						Wired_802.1X_EAP-TLS	EAP-TLS					svacs01	5411 EAP session timed out

Steps

11001  Received RADIUS Access-Request

11017  RADIUS created a new session

Evaluating Service Selection Policy

15004  Matched rule

15012  Selected Access Service - Wired_802.1X_EAP-TLS

11507  Extracted EAP-Response/Identity

12500  Prepared EAP-Request proposing EAP-TLS with challenge

11006  Returned RADIUS Access-Challenge

5411  EAP session timed out

At the switch I used "Authentication Open" to get the client working and capture traffic with wireshark.

Switch --> Request Identity --> Client

Switch <-- Response Identity <-- Client

Switch --> Request EAP-TLS --> Client

Switch --> Request EAP-TLS --> Client

Switch --> Request EAP-TLS --> Client

Switch --> Request Identity --> Client

Switch --> Request Identity --> Client

Switch --> Request Identity --> Client

What is missing ist the Switch <-- Response EAP-TLS <-- Client

Any ideas what is going wrong ? Maybe someone had this error before ?

Any suggestions how to debug this ?

Thank you very much for your help!

Mathias

[Nate Austin]

Hi Mathias,

It certainly looks like the client isn't responding to the EAP-Challenge proposing EAP-TLS. If it didn't support that mode then I would expect it to NAK it with another protocol type, so I don't think thats the problem.

However maybe if it couldn't find a certificate to present it could cause issues. Are you using the Native Windows XP Supplicant? If so can you verify that this client has a certificate issued to its machine name stored in its certificate store?

Also the supplicant logs could help here - I believe for Windows its logs directly to the Windows Event viewer so if you match up the time with a failure in the ACS there could be something interesting there.

Thanks,

Nate

[mi204978]

Hi @all,

I have this issue too. It occurs in our wireless environment. The problem for me is that I don't know which client (or clients) causes the error. The error occur many times per day.

Logged At	RADIUS Status	NAS Failure	Details	Username	MAC/IP Address	Access Service	Authentication Method	Network Device	NAS IP Address	NAS Port ID	CTS Security Group	ACS Instance	Failure  Reason
Sep 7,10 11:50:36.143 PM						dot1x wireless	PEAP					bfnetacs01	5411 EAP session timed out

Kind regards,

Michael

[Nate Austin]

Hi Michael,

Well, it is a pretty generic error in the sense that the timeout could be the client not responding or the switch not responding in the expected timeout value. The problem is that many things can cause it so there is no smoking gun.

It could be a legitimate timeout - if your clients have to enter a username and password then it could be longer than the dot1x timeouts on the switch and so the connection times out before the user can login.

It could be that one side received a packet that it didn't expect at that time of the flow. I have see that occur if "Fast Reconnect" is enabled on one side but not the other - Check that under your Access Policy config on ACS and on the client side in the authentication properties.

Also it could be a misbehaving supplicant if it occurs a lot from one client.

Thanks,

Nate

[#5]

Can you add a little more detail on how to configure Fast reconnect on the ACS side?  we have rolled to our first site (ACS 5 x) & I'm seeing this in the logs & i didn't see this in the lab (one AP so i couldn't simulate roaming).  We are using peap mschapv2 inner method for wireless clients on the windows native supplicate & we have Fast reconnect enabled on the client side but i'm not aware of how to enable this on the ACS side...

[#6]

Nevermind, found it...

Select System Administration > Configuration > Global System Options > PEAP Settings.

i should have looked at the help file prior to posting....

[m.leissle]

Hi Nathaniel,

thank you for your response. Maybe we can find out

However maybe if it couldn't find a certificate to present it could cause issues. Are you using the Native Windows XP Supplicant? If so can you verify that this client has a certificate issued to its machine name stored in its certificate store.

1. We use the native supplicant, configured with the "netsh command" to use "machine-authentication" only.

2. At the mmc-console, certificate snap-in I can see the correct machine-certifice, issued by our MS-CA and distributed to all clients.

I agree with you, that the client is not responding, but I have no idea why... about 50% of the clients respond, the others behave as described...

Also the supplicant logs could help here - I believe for Windows its logs directly to the Windows Event viewer so if you match up the time with a failure in the ACS there could be something interesting there.

I think there were no suspicious entries but I will take a close look next time.

Do you have any more ideas ?

thanks,

mathias

[helpdesk.s]

Hi

We also experience exactly this issue in our wireless environment. Last Sunday we upgraded our ACS to version 5.2.0.26 which at least fixed the bug CSCte30267 ACSView: Authentication Fail (EAP timed out) entries did not contain client information.

I can now see which clients that authenticate using the method PEAP-MSCHAPv2 sometimes produce this error on ACS. I am trying to pin-point the probelm and so far it seems that at least our MacBooks using Leopard (10.5.x) and Snowleaopard (10.6.x) generates the EAP session Timeout errors.

Troubleshooting continues.

Peter

[smathew]

I had the same problem. We were working fine when using vWLC on VMWare 4.1 Upgraded VMWare to 5.5 and problems started. Cisco tech had us build a new WLC running 7.4.110. Same problem. Solution was to change APs to Flexconnect and have them send auth requests directly to Cisco ACS.

Environment: Windows XP and 7 computers using Peap 802.1x to authenticate via virtual Cisco ACS connected to Windows AD Server. We are NOT using EAP-TLS - no cert.