John Paul wrote:
John Paul wrote:
The issue is that if a machine is authenticated and the server that did the authentication is down, the switch will contact the other server and the EAP conversation will fail, causing authentication to fail. Research indicates that this is because the client and server have agreed upon session specific symmetric keys that the new server does not know about. I don't think it's because of the establishment of symmetric session keys. Once a user has been authenticated, the *next* authentication session is completely independent.
I think it's that if fail-over happens in the *middle* of an EAP authentication, the new server won't have been participating in the TLS setup. Therefore, it doesn't know about the EAP conversation, and it rejects the session.
It's not happening in the middle of the conversation. Server 1 will send an "Access-Accept" packet and the switch enables the port. Then if server 1 goes down and you attempt to reauthenticate the port, the switch tries server 2. That is when it fails.
It is more likely that server 2 simply isn't configured correctly. Please post full debug (run "radiusd -X") output for the working (initial) request on server 1 and the failing (subsequent) request on server 2.