On 03/09/2019 23.03, Ullfig, Roberto Alfredo wrote:
If a rogue access point existed and a user walks within range of both a
legitimate and rogue AP while authenticating - could the EAP packets be
distributed between the two systems possibly resulting in:
EAP Response type 25, but no expected type known
on the legitimate server?
Before going into possible reasons, I'll quickly summarise what this
message means. This message is logged when a PEAP (type 25) message from
a RADIUS client is received, but Radiator couldn't find a currently
ongoing EAP authentication this response (message from client) belongs
to. In short: unexpected PEAP message from client was received.
One reason this could happen is when a RADIUS client has multiple RADIUS
servers configured and it decides for some reason to switch to another
server. It might be that the client's retransmission and failover
settings triggered a switch to another server when there was a problem
in the network and messages were dropped. These problems then led the
client to think its currently active RADIUS server was having problems.
I'd think that if the end user was communicating with a rogue AP first
and then switching to a trusted AP, then the trusted AP would force the
end user to start authentication from the scratch. This would mean
sending EAP-Response/Identity, not continuing with EAP-Response/PEAP.
I would first check if there's a possibility that a non-rogue AP or
controller was doing a switch to a different RADIUS server. If not, I'd
then take a look at the possible other causes.
Thanks,
Heikki
--
Heikki Vatiainen <h...@open.com.au>
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory,
EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc.
_______________________________________________
radiator mailing list
radiator@lists.open.com.au
https://lists.open.com.au/mailman/listinfo/radiator
