I am seeing 802.1X radius timeouts in the event log. I have increased the timeout to 10 seconds and they persist. packet captures on the radius server don't indicate problem neither do packet captures on the core switch at site that sits between the APs and the Radius server.
Interestingly radius timeouts only occur with EAP-TLS. Corporate SSID using 802.1x EAP_TLS experience RADIUS timeouts but Guest which also uses the same radius server for authenticating guest users doesn't experience timeouts
Packet captures on site show 802.1x users authenticating successfully but approx 1 sec after receiving the RADIUS ACCPET message you the client disassociate with the reason being RADIUS timeout. I can't see even seen on my capture what message is sent to the radius server after RADIUS ACCEPT
I have increased to the maximum of 10 secs. I have a change planned to upgrade the AP's in one network to 29.7 as per Meraki TAC suggestion but I don't see it fixing anything.
So the customer reported random users having connectivity issues. The Windows NLA feature would indicate that they had loss network connectivity which coincided with events in the log.
The bit I am trying to get my head round is that I don't get timeouts on the Guest network which users the same radius servers but they don't user eap-tls.
What does the event log say on the client? What reason does it give for disconnecting?
It might be the client is refusing the connection after it is accepted. Perhaps the client does not like the RADIUS server certificate or something like that.
I would have to check with the customer. In the Meraki log it says client disassociates with Radius Timeout error. But this tends to happen 1 second after the client has successfully authenticated. The customer brough it to us as they are seeing Windows NLA icon on their task bar. I don't think the two are related but customer is keen to get to the bottom of the timeouts.
Meraki have recommended a firmware upgrade to 29.7 on the AP's. Planned for later this week. I have run numerous packet captures across the estate and can't see how their can be a timeout with the setting at 10 seconds.
I don't think you are having an actual timeout - I believe one end (either the client or the RADIUS server) is refusing to respond to a message, which looks like a timeout from a packet capture perspective.
But I suspect on either the client or the RADIUS server, there will be additional information.
The interesting thing is this that this only occurs on eap-tls - guest access also uses the radius server but we don't see radius timeouts but that use PEAP and the Cisco ISE internal user database for authentication. So it could be an eap-tls issue on ISE or the client. Do you know what message would be sent after a radius accept message as I would expect that to be final message
>The interesting thing is this that this only occurs on eap-tls
Perhaps they haven't been configured to trust the root CA certficate.
Perhaps they require a minimum of a SHA2 signed root CA certificate and it is only SHA1 signed.
>what message would be sent after a radius accept message as I would expect that to be final message
Hard to say. Could be COA. Could be an additional or secondary challenge. Need to check client log to see what it is saying.