How to cleanly shut down a PEAP TLS tunnel

Joe Garcia joe27256 at
Mon Sep 11 11:36:52 UTC 2023

I've got a client that tries to shut down the TLS tunnel used for PEAP
after running through the full authentication process and getting the
Access-Accept/Success at the end.  However the Access-Accept/Success
comes in without a State attribute, and if the TLS Close-Alert
(appropriately wrapped in several layers of outer protocols) is sent
that way then FreeRADIUS reports:

(18) eap: ERROR: EAP requires the State attribute to work, but no
State exists in the Access-Request packet.
(18) eap: ERROR: The RADIUS client is broken.  No amount of changing
FreeRADIUS will fix the RADIUS client.
(18) eap: Either EAP-request timed out OR EAP-response to an unknown EAP-request

If OTOH I use the State value from the last message preceding the
Access-Accept/Success I get:

(37) eap: ERROR: rlm_eap (EAP): No EAP session matching state 0x57f74ed950ff57da
(37) eap: Either EAP-request timed out OR EAP-response to an unknown EAP-request

What's the correct way to perform a clean shutdown of the TLS tunnel
after completing the PEAP authentication process?  Or do you just
leave it hanging? Although no two diagrams seem to be able to agree on
what happens at this point, one example is this:

which tears down the tunnel at step 15 and then the client gets the
Access-Accept/Success at step 16/17, while with FreeRADIUS I'm getting
the Access-Accept/Success before the TLS tunnel is torn down and then
one of the two errors above with an attempt to tear down the tunnel.


More information about the Freeradius-Users mailing list