It looks like FreeRADIUS is currently checking whether session resumption is enabled very late during EAP-PEAP negotiation. Even the protected result indication for success is completed before FreeRADIUS does this and sends EAP-Failure. However, at that point the client is going to discard the EAP-Failure since the only allowed message after successfully completed result indication is EAP-Success. Would it be possible to move the session resumption enabled/disabled check to be done much earlier during the process? Ideally, this would be done when processing the TLS ClientHello so that server could just fall back to using full authentication without causing authentication problems. If that is not feasible for some reason, it would be useful for the protected result indication to result in Failure, not Success, so that the peer implementation would actually accept the EAP-Failure in the end. The code that triggers the current behavior is in eap_tls.c, eaptls_success(). Debug log shows this: [eap] EAP/peap [eap] processing type peap [peap] processing EAP-TLS [peap] eaptls_verify returned 7 [peap] Done initial handshake [peap] eaptls_process returned 7 [peap] EAPTLS_OK [peap] Session established. Decoding tunneled attributes. [peap] Received EAP-TLV response. [peap] Success [peap] FAIL: Forcibly stopping session resumption as it is not allowed. The EAP-TLV there was the end of the protected result (Success) indication. -- Jouni Malinen PGP id EFC895FA