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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
