Re: Re: "use_tunnel_reply" not working in EAP-PEAP (Proxied as plain MSCHAPv2) in eap.conf

[Nitin Bhardwaj]

/

Phil Mayers wrote:
>  The (untested) patch below might help on 2.1.x:
>
>  
https://github.com/philmayers/freeradius-server/commit/3c1ed71cde100268dba57cbd87953af2bfda6d87
>
>
>  ...or for 3.x:
>
>  
https://github.com/philmayers/freeradius-server/commit/6877b70f442536c93ed097f3c9f6d17d9c960b19

   Added, thanks.

   Alan DeKok.

/Alan,

Just did git pull (master branch), and tried - it failed - as described 
by Phil in an earlier post, since mschapv2 callback is not called

-
(19) # Executing group from file /usr/local/etc/raddb/sites-enabled/default
(19)   group authenticate {
(19)  - entering group authenticate {...}
(19) eap : Request found, released from the list
(19) eap : EAP/peap
(19) eap : processing type peap
(19) peap : processing EAP-TLS
(19) peap : eaptls_verify returned 7
(19) peap : Done initial handshake
(19) peap : eaptls_process returned 7
(19) peap : FR_TLS_OK
(19) peap : Session established.  Decoding tunneled attributes.
(19) peap : Peap state send tlv success
(19) peap : Received EAP-TLV response.
(19) peap : Client rejected our response.  The password is probably 
incorrect.

(19) peap : We sent a success, but received something weird in return.
(19) eap : Handler failed in EAP/peap
(19) eap : Failed in EAP select
(19)   [eap] = invalid
(19) Failed to authenticate the user.
(19) Using Post-Auth-Type Reject
-

Then tried with removing this patch: 
https://lists.freeradius.org/pipermail/freeradius-users/2011-April/msg00295.html
and it is working properly like in 2.x branch. Hence I think, also you 
need to remove this patch.


--
Nitin.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: "use_tunnel_reply" not working in EAP-PEAP (Proxied as plain MSCHAPv2) in eap.conf

[Nitin Bhardwaj]

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. 

Ok. So do you think this patch is fit to be brought into mainline-2.x ?

I will try the 3.x patch too, and let you know soon.

--
Nitin.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: "use_tunnel_reply" not working in EAP-PEAP (Proxied as plain MSCHAPv2) in eap.conf

[Alan DeKok]

Phil Mayers wrote:
> The (untested) patch below might help on 2.1.x:
> 
> https://github.com/philmayers/freeradius-server/commit/3c1ed71cde100268dba57cbd87953af2bfda6d87
> 
> 
> ...or for 3.x:
> 
> https://github.com/philmayers/freeradius-server/commit/6877b70f442536c93ed097f3c9f6d17d9c960b19

  Added, thanks.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: "use_tunnel_reply" not working in EAP-PEAP (Proxied as plain MSCHAPv2) in eap.conf

[Phil Mayers]

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.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Re: "use_tunnel_reply" not working in EAP-PEAP (Proxied as plain MSCHAPv2) in eap.conf

[Nitin Bhardwaj]

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/3c1ed71cde100268dba57cbd87953af2bfda6d87 



...or for 3.x:

https://github.com/philmayers/freeradius-server/commit/6877b70f442536c93ed097f3c9f6d17d9c960b19 




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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Re: "use_tunnel_reply" not working in EAP-PEAP (Proxied as plain MSCHAPv2) in eap.conf

[Nitin Bhardwaj]

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.html 



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/3c1ed71cde100268dba57cbd87953af2bfda6d87 



...or for 3.x:

https://github.com/philmayers/freeradius-server/commit/6877b70f442536c93ed097f3c9f6d17d9c960b19 




Thanks for the patches, I'll give them a shot and report back.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: "use_tunnel_reply" not working in EAP-PEAP (Proxied as plain MSCHAPv2) in eap.conf

[Phil Mayers]

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.html


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/3c1ed71cde100268dba57cbd87953af2bfda6d87

...or for 3.x:

https://github.com/philmayers/freeradius-server/commit/6877b70f442536c93ed097f3c9f6d17d9c960b19
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Re: "use_tunnel_reply" not working in EAP-PEAP (Proxied as plain MSCHAPv2) in eap.conf

[Nitin Bhardwaj]

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.html

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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: "use_tunnel_reply" not working in EAP-PEAP (Proxied as plain MSCHAPv2) in eap.conf

[Alan Buxey]

Hi,

>   3.0 hasn't been released yet.  It has all kinds of goodness which
> makes it better than 2.1.x.  However, more is coming.  So the 3.0
> release is planned for early September.

yes, not released yet - but it is official - people can run it now
(if they want ;-) ) - certainly having a few more people running
it more in anger is useful BEFORE the 3.0.0 release :-)

alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: "use_tunnel_reply" not working in EAP-PEAP (Proxied as plain MSCHAPv2) in eap.conf

[Alan DeKok]

Alan Buxey wrote:
> Hi,
> 3.x is an official release - 

  ?

  3.0 hasn't been released yet.  It has all kinds of goodness which
makes it better than 2.1.x.  However, more is coming.  So the 3.0
release is planned for early September.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: "use_tunnel_reply" not working in EAP-PEAP (Proxied as plain MSCHAPv2) in eap.conf

[Phil Mayers]

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.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: "use_tunnel_reply" not working in EAP-PEAP (Proxied as plain MSCHAPv2) in eap.conf

[Phil Mayers]

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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: "use_tunnel_reply" not working in EAP-PEAP (Proxied as plain MSCHAPv2) in eap.conf

[Nitin Bhardwaj]

/

Hi,

>  Sigh!
>
>  Tried 3.x sometime back, it was seg-faulting left-and-right in my

3.0 is not a static beast. sometime back is sometime back! there have been
several key fixes to it - and more when people run it.

its no good saying seg-faulting left-ad-right' if those issues arent
reported to the dev list - as they wont get fixed unless people report
them - or run the server to find them ;-)

>  scenario, so want to stay with "official" and stable releases only.

3.x is an official release - its not some random fork by third party

alan
/Sorry, what I meant was, Looking at the descriptions of various 
branches here : http://git.freeradius.org/ :


o master  - 
The next "major" release, which will have new features and other changes.
o v2.1.x  - 
The "long term support" release. The only changes to this code will be 
minor bug fixes. All new development is done in the "stable" branch.


I decided to take the "long-term-support" release :)

--
Nitin.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: "use_tunnel_reply" not working in EAP-PEAP (Proxied as plain MSCHAPv2) in eap.conf

[Alan Buxey]

Hi,

> Sigh!
> 
> Tried 3.x sometime back, it was seg-faulting left-and-right in my 

3.0 is not a static beast. sometime back is sometime back! there have been
several key fixes to it - and more when people run it.

its no good saying seg-faulting left-ad-right' if those issues arent
reported to the dev list - as they wont get fixed unless people report
them - or run the server to find them ;-)

> scenario, so want to stay with "official" and stable releases only.

3.x is an official release - its not some random fork by third party

alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: "use_tunnel_reply" not working in EAP-PEAP (Proxied as plain MSCHAPv2) in eap.conf

[Nitin Bhardwaj]

On 07/07/2011 01:52 PM, Alan Buxey wrote:



use version 3 ?

the things you want work, why stick to 2.1.x?

Alan


Sigh!

Tried 3.x sometime back, it was seg-faulting left-and-right in my 
scenario, so want to stay with "official" and stable releases only.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: "use_tunnel_reply" not working in EAP-PEAP (Proxied as plain MSCHAPv2) in eap.conf

[Alan Buxey]

use version 3 ?

the things you want work, why stick to 2.1.x?

Alan

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: "use_tunnel_reply" not working in EAP-PEAP (Proxied as plain MSCHAPv2) in eap.conf

[Nitin Bhardwaj]

/

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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: "use_tunnel_reply" not working in EAP-PEAP (Proxied as plain MSCHAPv2) in eap.conf

[Alan DeKok]

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.

> 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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: "use_tunnel_reply" not working in EAP-PEAP (Proxied as plain MSCHAPv2) in eap.conf

[Phil Mayers]

On 07/05/2011 06:03 PM, Nitin Bhardwaj wrote:

Hello All,

I'm using FreeRADIUS 2.1.11 as a proxy for authenticating PEAP
clients with RADIUS server not supporting EAP.

All is working well except that when I use
"proxy_tunneled_request_as_eap = no" in eap.conf, FreeRADIUS is not
passing back all the AVPs sent by RADIUS server in
Access-Accept(MSCHAPv2) to the Client, only few ones.


Be specific. Which ones?

Better yet, show a debug of it not working.



But when I set it as "proxy_tunneled_request_as_eap = yes",
FreeRADIUS is relaying back all the AVPs received from the RADIUS
server properly.






eap.conf:  eap { peap { copy_request_to_tunnel = yes
use_tunneled_reply = yes proxy_tunneled_request_as_eap = no
virtual_server = "proxy-inner-tunnel" } }

Hence, in spite of setting "use_tunneled_reply = yes", why isnt FR
copying all attributes in Access-Accept back to client ? Is this some
bug, fixed in 3.x ?


3.x is not released yet.

I don't think there are any fixed related to this in "master" (to become 
3.x) but there might be; please provide more details as above, so we can 
try to reproduce.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

"use_tunnel_reply" not working in EAP-PEAP (Proxied as plain MSCHAPv2) in eap.conf

[Nitin Bhardwaj]

Hello All,

I'm using FreeRADIUS 2.1.11 as a proxy for authenticating PEAP clients with 
RADIUS server not supporting EAP.

All is working well except that when I use "proxy_tunneled_request_as_eap = no" 
in eap.conf, FreeRADIUS is not passing back all the AVPs sent by RADIUS server 
in Access-Accept(MSCHAPv2) to the Client, only few ones.

But when I set it as "proxy_tunneled_request_as_eap = yes", FreeRADIUS is 
relaying back all the AVPs received from the RADIUS server properly.

eap.conf:

eap {
 peap {
copy_request_to_tunnel = yes
use_tunneled_reply = yes
proxy_tunneled_request_as_eap = no
virtual_server = "proxy-inner-tunnel"
 }
}

Hence, in spite of setting "use_tunneled_reply = yes", why isnt FR copying all 
attributes in Access-Accept back to client ?
Is this some bug, fixed in 3.x ?

--
Nitin

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html