MACSEC on Cisco 3750-X and FreeRADIUS 2.2.5
aland at deployingradius.com
Tue Mar 3 16:54:42 CET 2015
On Mar 3, 2015, at 10:33 AM, Phil Mayers <p.mayers at imperial.ac.uk> wrote:
> Well, it expects a response or a plain NAK there because that's what MS-PEAP says are the only valid replies, once you pick apart the state machine.
> It's probably a good idea to be looser and accept the expanded NAK too, on the FR side; no real harm to it.
It’s not an expanded NAK. It’s a gigantic piece of garbage. The supplicant should be thrown in the garbage. It goes like this:
FreeRADIUS does PEAP. Once the inner tunnel is set up, FR sends an EAP-MSCHAPv2 challenge packet.
The supplicant responds with an extended type:
0x021d 0046 fe extended type
000000 IETF Private enterprise code
021d 003a 31 ???? Another EAP packet with EAP-Type 49, EAP-IKEv2 ???
And then this:
The supplicant is a piece of garbage. There is NO REASON to send an extended type packet. On top of that, the contents of the extended type are the actual EAP type data. NOT another EAP packet with EAP header, length, etc.
All of this nonsense could have been avoided if the OP posted the debug log as suggested in the FAQ, README, “man” pages, web pages, and daily on this list. But no…making it hard for people to help you is a *great* idea.
More information about the Freeradius-Users