Re: "use_tunnel_reply" not working in EAP-PEAP (Proxied as plain MSCHAPv2) in eap.conf
/
Nitin Bhardwaj wrote:
Hi,
Please edit your posts. It's not nice to go through hundreds of lines of garbage in order to read the *real* content of the message. /Alan, I posted the output of "radiusd -X" in the previous message as is the norm on the mailing-list, and replied to the same in last message. That is not a *garbage*, isn't it ?
/
Found out that this works perfectly fine in freeradius 3.0.0 (master git branch).
That's nice to know.
Can anyone please suggest which patches I need to back-port to 2.1.11 to make this work in 2.1.x branch too ?
You can't. The code is *completely* different.
Alan DeKok. /In 2.1.11, I observed that the problem happens when you set "proxy_tunneled_request_as_eap = no" (with "default_eap_type = mschapv2"). Hence it seems the function mschap_postproxy() in rlm_eap_mschapv2.c is somehow wiping off the extra attributes.
Comparing radiusd -X logs of 2.x with 3.x, corroborate this observation: -------------------------< snip-log 2.x >------------------------------- # Executing section post-proxy from file /usr/local/etc/raddb/sites-enabled/default +- entering group post-proxy {...} [eap] Doing post-proxy callback [eap] Passing reply from proxy back into the tunnel. server proxy-inner-tunnel { [eap] Passing reply back for EAP-MS-CHAP-V2 # Executing section post-proxy from file /usr/local/etc/raddb/sites-enabled/proxy-inner-tunnel +- entering group post-proxy {...} [eap] Doing post-proxy callback rlm_eap_mschapv2: Passing reply from proxy back into the tunnel 0x8e86e20 2. rlm_eap_mschapv2: Authentication succeeded. MSCHAP Success ++[eap] returns ok WARNING: Empty post-auth section. Using default return values. } # server proxy-inner-tunnel -------------------------< snip-end >------------------------------- -------------------------< snip-log 3.x >--------------------------- (8) # Executing section post-proxy from file /usr/local/etc/raddb/sites-enabled/default (8) group post-proxy { (8) - entering group post-proxy {...} (8) eap : Doing post-proxy callback (8) eap : Passing reply from proxy back into the tunnel. server proxy-inner-tunnel { (8) eap : Passing reply back for EAP-MS-CHAP-V2 (8) # Executing section post-proxy from file /usr/local/etc/raddb/sites-enabled/proxy-inner-tunnel (8) group post-proxy { (8) - entering group post-proxy {...} (8) [eap] = noop (8) WARNING: Empty post-auth section. Using default return values. } # server proxy-inner-tunnel -------------------------< snip-end >------------------------------- In 3.x code, We are returning a RLM_MODULE_NOOP from eap_post_proxy() : 582 /* 583 * Just in case the admin lists EAP in post-proxy-type Fail. 584 */ 585 if (!request->proxy_reply) return RLM_MODULE_NOOP; But we are not doing so in 2.1.11 code. We call the MSCHAPv2 callback, i.e. mschap_postproxy(), which might be wiping off the attributes. So, my question is: will adding this code patch to 2.x code prudent to make it work ? Or we need to fix the mschapv2 handler itself : mschap_postproxy() in rlm_eap_mschapv2.c,so that it retains the extra attributes sent by the RADIUS home server ? Please advise. -- Thanks, Nitin.
In 3.x code, We are returning a RLM_MODULE_NOOP from eap_post_proxy() : 582 /* 583 * Just in case the admin lists EAP in post-proxy-type Fail. 584 */ 585 if (!request->proxy_reply) return RLM_MODULE_NOOP;
But we are not doing so in 2.1.11 code. We call the MSCHAPv2 callback, i.e. mschap_postproxy(), which might be wiping off the attributes.
So, my question is: will adding this code patch to 2.x code prudent to make it work ? Or we need to fix the mschapv2 handler itself : mschap_postproxy() in rlm_eap_mschapv2.c,so that it retains the extra attributes sent by the RADIUS home server ?
This code is complex and needs to be treated with care. There were changes recently related to failures when proxying PEAP inner as eap versus non-eap, and this code was implicated. Basically, be careful fiddling with it.
On 01:29 AM, Phil Mayers wrote:
In 3.x code, We are returning a RLM_MODULE_NOOP from eap_post_proxy() : 582 /* 583 * Just in case the admin lists EAP in post-proxy-type Fail. 584 */ 585 if (!request->proxy_reply) return RLM_MODULE_NOOP;
But we are not doing so in 2.1.11 code. We call the MSCHAPv2 callback, i.e. mschap_postproxy(), which might be wiping off the attributes.
So, my question is: will adding this code patch to 2.x code prudent to make it work ? Or we need to fix the mschapv2 handler itself : mschap_postproxy() in rlm_eap_mschapv2.c,so that it retains the extra attributes sent by the RADIUS home server ?
This code is complex and needs to be treated with care. There were changes recently related to failures when proxying PEAP inner as eap versus non-eap, and this code was implicated.
Basically, be careful fiddling with it.
Thanks Phil. I found this recent patch added to 2.x, regarding inner-MSCHAP broken: https://lists.freeradius.org/pipermail/freeradius-users/2011-April/msg00295.... 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 ? 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!! Please throw some light ! -- Nitin.
On 07/07/11 14:43, Nitin Bhardwaj wrote:
Thanks Phil.
I found this recent patch added to 2.x, regarding inner-MSCHAP broken: https://lists.freeradius.org/pipermail/freeradius-users/2011-April/msg00295....
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. The (untested) patch below might help on 2.1.x: https://github.com/philmayers/freeradius-server/commit/3c1ed71cde100268dba57... ...or for 3.x: https://github.com/philmayers/freeradius-server/commit/6877b70f442536c93ed09...
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: https://lists.freeradius.org/pipermail/freeradius-users/2011-April/msg00295....
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. Phil,
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:
https://github.com/philmayers/freeradius-server/commit/3c1ed71cde100268dba57...
...or for 3.x:
https://github.com/philmayers/freeradius-server/commit/6877b70f442536c93ed09...
Thanks for the patches, I'll give them a shot and report back.
On 01:29 AM, Nitin Bhardwaj wrote:
On 01:29 AM, Phil Mayers wrote:
The (untested) patch below might help on 2.1.x:
https://github.com/philmayers/freeradius-server/commit/3c1ed71cde100268dba57...
...or for 3.x:
https://github.com/philmayers/freeradius-server/commit/6877b70f442536c93ed09...
Thanks for the patches, I'll give them a shot and report back.
Phil, the patch (2.x) is working like a charm :). (also confirmed that there is no mem-leak, by inserting a RDEBUG in free_data()). However, one doubt: Shouldn't this code be conditional based on whether "use_tunneled_reply" is yes/no. Presently the outer PEAP does take care of it, is this taken care of in this callback (mschap_postproxy) ? -- Nitin
On 08/07/11 11:20, Nitin Bhardwaj wrote:
However, one doubt: Shouldn't this code be conditional based on whether "use_tunneled_reply" is yes/no. Presently the outer PEAP does take care of it, is this taken care of in this callback (mschap_postproxy) ?
No. The code doesn't need to be conditional, because copying of the attributes to the final, outer, access-accept is already conditional on "use_tunneled_reply" - that's what it does.
Phil Mayers wrote:
The (untested) patch below might help on 2.1.x:
https://github.com/philmayers/freeradius-server/commit/3c1ed71cde100268dba57...
...or for 3.x:
https://github.com/philmayers/freeradius-server/commit/6877b70f442536c93ed09...
Added, thanks. Alan DeKok.
On 07/07/11 07:55, Nitin Bhardwaj wrote:
/
Nitin Bhardwaj wrote:
Hi,
Please edit your posts. It's not nice to go through hundreds of lines of garbage in order to read the *real* content of the message. /Alan, I posted the output of "radiusd -X" in the previous message as is the
Yes. Then, when you replied to yourself, you quoted it in it's entirety, thus repeating it unnecessarily.
norm on the mailing-list, and replied to the same in last message. That is not a *garbage*, isn't it ?
It is if you send it twice, because you didn't trim the quoted text when replying to yourself.
participants (3)
-
Alan DeKok -
Nitin Bhardwaj -
Phil Mayers