Hi, I found an other minor bug in ttls implementation In configuration where Freeradius proxyies tunneled ttls message to a home server Radius, FreeRadius doesn't send good message after having received Access-Reject/EAP-Failure from radius home server. Indeed, FreeRadius sends to the NAS an Access-Reject but doesn't include EAP/Failure attribute. This is the same case if an unknown Radius message is received from the radius home server. So the peer isn't informed of this decision and retransmits his last request after its watchdog wakes up. Here are the modifications I done on my server to correct the bug. ttls.c v1.20 process_reply function : l712 : I replaced "rcode=RLM_MODULE_REJECT" by "rcode=RLM_MODULE_INVALID" --> Invalid message and Rejected Message wasn't differentiated eap_ttls_postproxy function : l819 : replace "return 0" by "break" --> So eaptls_fail of l839 can be called to add EAP/FAILURE message in case of RLM_MODULE_REJECT rlm_eap.c v1.30 eap_post_proxy function : l547 : I moved "rcode = eap_compose(handler)" to l538 and I removed "rcode =" --> With this modification eap_compose is called whatever the return code and the eap attribute can be inserted even if the message is rejected Fabien Marotte