Hello Alexander, all, Please see inline. (snip)
Have you considered comparing the difference in the RADIUS packets going to-and-fro in both cases; the one where authentication works and the one where it does not? What do you see?
Yes I did, although I mostly concentrated on the 4-way handshake of the client because this is where it is failing compared to without session resumption. The end-client does not follow up the 1st message of the 4-way handshake of the NAS, but decides to restart the full authentication.
It's worth always running tcpdump on the RADIUS server and looking at what is spat out on the wire; can be easier than trawling the FreeRADIUS output when you need to compare two authentication runs. Handy as a initial pass to give you a hint at what is wrong.
I am running wireshark :-)
Anyway, so what I thought to do is to go to the post-auth section of my inner-server and add the following to remove the MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes added by the inner-server and let the
default
add its own.
update reply { MS-MPPE-Recv-Key !* 0x00 MS-MPPE-Send-Key !* 0x00 }
Is the logic behind this fine or do you reckon it might break something else in the future?
Remote 'eap' from the inner server, I think this is linked to your pap/mschap modules noop'ing as the request is already primed for passing to the eap module as eap is added additional MS-MPPE keys.
So mschapv2 in the inner tunnel adds keys for the first time (I see an entry about that on the log) and you are saying that the eap adds additional keys? Why does it do that without checking if keys already exist as attributes in the packet? By the way it seems that the pair of keys added by mschapv2 are shorter than the eap ones and I am removing the mschav2 with the update reply as above in a post-auth.
If you need an inner-eap (say for EAP-GTC, but then we would need Alan to apply a patch to make GTC useful</grumble>) then you should place that *after* pap/chap/mschap iirc.
Here is my inner-auth (the ldap bits I left there as you might be interested in them, however others might like the outer:Cleartext-Password 'override' and want to also palm the error handling): ---- server auth { authorize { if ((outer.request:EAP-Message)) { update outer.request { User-Name := "%{request:User-Name}" } update reply { User-Name := "%{request:User-Name}" } }
validate_username
suffix
if ((outer.request:EAP-Message) && Realm != "%{config:local.MY.realm}") { update outer.reply { Reply-Message := "Realm is '%{Realm}' on Inside" } reject }
# if the password is passed to us use it, otherwise yank
it
from LDAP if ((outer.request:Cleartext-Password)) { update control { Cleartext-Password := "%{outer.request:Cleartext-Password}" } } else { ldap-login
# some accounts are glitched and do not have a UP :( if (ok && !(control:Cleartext-Password)) { update outer.reply { Reply-Message := "No eDirectory UP" } reject } }
pap chap mschap
update reply { Auth-Type := "%{control:Auth-Type}" } }
authenticate { Auth-Type PAP { pap } Auth-Type CHAP { chap } Auth-Type MSCHAP { mschap } } }
That is very interesting! I think though from the above, the only thing that I need is your first if in my authorize section (right?). However the problem now does not seem to lie in the fact that openssl does not add entries in the cache, I see the following in every coming request ; #Debug: SSL: adding session 5705534d65ddd08de3b8649528274c1bc4e3d648bef7b643ffaf0f647afcac73 to cache ... what I never ever see though is to try and do session resumption (i.e. see "Skipping Phase2 due to session resumption"). How can I fix/debug that? Is anyone using session resumption successfully in 2.1.10? Thanks a lot, Panos