"use_tunnel_reply" not working in EAP-PEAP (Proxied as plain MSCHAPv2) in eap.conf
nbhardwaj at merunetworks.com
Fri Jul 8 09:37:50 CEST 2011
On 01:29 AM, Phil Mayers wrote:
> On 07/07/11 14:43, Nitin Bhardwaj wrote:
>> Thanks Phil.
>> I found this recent patch added to 2.x, regarding inner-MSCHAP broken:
> Yes, that's what I was thinking of.
>> I think this patch fixed the original issue, but the mschapv2 callback
>> is not preserving *all* the attributes
>> received from the home server. Any ideas on how to fix
>> mschap_postproxy ?
> It is hard. When the plain MSCHAP response comes back (as an
> Access-Accept) it has to be turned into an EAP-MSCHAPv2
> Access-Challenge. The PEAP attribute-saving code does not look at
> Access-Challenge packets - only Access-Accept.
> Basically, mschap_postproxy would need to save the attributes, then
> insert them in the final Access-Accept.
>> Another thing, this patch is not carried over to the 3.x branch and
>> mschap_postproxy in both 2.x and 3.x
>> are almost same (except for some DEBUG statements), so there must be
>> something else different between
>> 2.x and 3.x - which makes this work in 3.x and not in 2.x!!
> Are you sure this is working in 3.x?
> If 3.x is missing the above patch, post-proxy should fail completely;
> the Access-Accept won't be re-written to an EAP-MSCHAP
> access-challenge, and EAP should fail.
My mistake. I checked again - The 3.x is working only with the Intel's
supplicant client (which even 2.x works with the patch applied),
not with either native Windows' client (both on same Windows XP) or
Juniper's Odyssey client ! I guess Intel's supplicant is more permissive
(and non-conforming to the RFCs :).
I had not tried more than one supplicants earlier with 3.x. Hence 2.x
and 3.x behaviour is identical (failure!).
> The (untested) patch below might help on 2.1.x:
> ...or for 3.x:
Thanks for the patches, I'll give them a shot and report back.
More information about the Freeradius-Users