Hello all, I am resending this to the list as the debugging output was more than 100KB and the message was rejected. Alexander who was copied in my email, kindly provided feedback already. In short, "use_tunneled_reply = yes" should be able to solve the problem with session resumption in FR 2.1.10, although I understand that break the end client's privacy as it reveals its identity to the NAS. When I test it I'll get back to you as I am guessing this interests more people. Cheers, Panos Debug output here : http://pastebin.com/7u1tjbYE
-----Original Message----- From: Panagiotis Georgopoulos [mailto:panos@comp.lancs.ac.uk] Sent: Friday, September 24, 2010 04:17 To: 'FreeRadius users mailing list'; 'Alexander Clouter' Subject: RE: Session Resumption fails
Hi Alexander, all
Thanks a lot for your reply, it helped my understanding of what is occurring. Please see below for my comments.
Panagiotis Georgopoulos <panos@comp.lancs.ac.uk> wrote:
I have a client machine that authenticates to FreeRadius using EAP-TTLS over Access_Point_1 just fine. When I roam the client to Access_Point_2 and tries to authenticate again to FreeRadius, session resumption seems to be failing with the following error.
[snipped]
One thing to note on the above is that there is no cached
information,
which seems strange as the client was authenticated some minutes over Access_Point_1. The other thing is that user authentication fails completely and the client resides to restart EAP-TTLS from the start that finishes successfully.
The session cache stores what is in the *reply* packet of the inner request (if that makes sense).
In your eap.conf file, you refer to a virtual server to palm off requests to once the EAP layer has been peeled off. In that virtual server say in the authorize{} section: ---- update reply { User-Name := "%{request:User-Name}" } ----
Now you will find on resumption the username appears magically; session resumption is a feature of SSL/TLS and so the user-name is not accessible; hence the need to dig into the cache.
I also recommend that you also do: ---- update outer.request { User-Name := "%{request:User-Name}" } ----
I am afraid your suggestion though to add the above in my inner-tunnel virtual server didn't solve the problem. After having searched the archives of the list, I found out that this is an OpenSSL bug and there is a fix in FreeRadius 2.1.10 for it.
I just compiled 2.1.10 and I verify that I don't see resuming sessions failing with this no information in the cache :
Info: [ttls] Skipping Phase2 due to session resumption Info: [ttls] WARNING: No information in cached session!
However, I am not seeing the correct behaviour either :-/
I am seeing the server adding information in the cache :
- Debug: SSL: adding session 1d6029bbddba233cd443d692b968df093237d9ad982f9ccc8a2defcd3edeb243 to cache - Info: [ttls] (other): SSL negotiation finished successfully - Debug: SSL Connection Established
.. but it *never* says that it tries to e.g. skip phase 2 and try resumption (as I was seeing with FR 2.1.8).
However in some occasions it says :
- Info: [ttls] WARNING: No information to cache: session caching will be disabled for this session. - Debug: SSL: Removing session 69c204b29e84878591c19645ed74c1ff4b656c30f66adad78d268df65d2e1d14 from the cache
Does anyone have any pointers/suggestions? Anyone who managed to do session resumption with 2.1.10?
Thanks a lot in advance, Panos
Ps. By the way, you can find attached my radiusd debugging output with a client trying to authenticate over different NASs. All authentications succeed, and info in the cache is stored, but FR never resumes a session. (nb. in the attached debug, I am restarting my NASs first before the client starts roaming from one NAS to the other using EAP-TTLS)