[RADIATOR] EAP Response type 25, but no expected type known - Rogue Access Point?

[Ullfig, Roberto Alfredo]

No, this is our eduroam server - it's a single server. Our other servers started doing this as well at about the same time (it's only a .0035% failure rate with this error) with over 2,000,000 successful attempts a day (so only a few 10s of these) - so yes we thought it was a load-balancing problem at first but that's ruled out with eduroam running on only one server. It does not make use of any load-balancing device.

While this might be true:

"..then the trusted AP would force the  end user to start authentication from the scratch"

That user's device is still going to send that UDP packet to the new AP and end up on our server no? Also, it doesn't have to be  a rogue AP does it, it could be someone else's legitimate AP that just happens to be near one of our APs.

---
Roberto Ullfig - rullfig at uic.edu
Systems Administrator
Enterprise Architecture and Development | ACCC
University of Illinois - Chicago
________________________________
From: radiator <radiator-bounces at lists.open.com.au> on behalf of Heikki Vatiainen <hvn at open.com.au>
Sent: Wednesday, September 4, 2019 4:52 AM
To: radiator at lists.open.com.au <radiator at lists.open.com.au>
Subject: Re: [RADIATOR] EAP Response type 25, but no expected type known - Rogue Access Point?

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 <hvn at 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 at lists.open.com.au
https://lists.open.com.au/mailman/listinfo/radiator
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20190904/0e678a92/attachment.html>