[RADIATOR] strange PEAP behavior

[Hugh Irvine]

Hello Andrew -

As usual I will need to see a copy of the configuration file and a trace 4 debug showing the whole packet sequence when this problem occurs.

regards

Hugh


On 31 Jul 2010, at 01:19, Andrew Clark wrote:

> Hi,
> 
> I'm not sure this is actually a Radiator problem, but I'm seeing strange behavior for EAP-PEAP clients in my authentication log.  I have a Trapeze networks wireless system which is configured to do pass-through for EAP requests to my Radiator servers.  I have a pretty vanilla setup for EAP on Radiator - I terminate the EAP request, convert the inner request to a Radius-MSCHAPv2 request and then proxy it to another server.
> 
> My authlog format is configured as follows:
> 
>         # add radius server hostname, client ident, handler ident, NAS IP address, and strip passwords
>         SuccessFormat %l:%h:%{Client:Identifier}%{OSC-Client-Identifier}:%{Handler:Identifier}:%N:%u:OK
>         # add failure code here too
>         FailureFormat %l:%h:%{Client:Identifier}%{OSC-Client-Identifier}:%{Handler:Identifier}:%N:%u:FAIL(%1)
> 
> A normal authentication looks like this (I've replaced the username with "foo"):
>  
> Tue Jul 27 12:41:36 2010:server3:WIRELESS:eap_converted:134.84.143.177:foo:OK
> Tue Jul 27 12:41:36 2010:server3:WIRELESS:eap_inner_peap:134.84.143.177:anonymous:OK
> Tue Jul 27 12:41:36 2010:server3:WIRELESS:uofm_secure:134.84.143.177:foo:OK
> 
> But then sometimes I see this (same user in this case):
> 
> Tue Jul 27 12:42:07 2010:sever3:WIRELESS:uofm_secure:134.84.143.177:foo:OK
> Tue Jul 27 12:42:20 2010:server3:WIRELESS:uofm_secure:134.84.143.177:foo:OK
> Tue Jul 27 12:42:32 2010:server3:WIRELESS:uofm_secure:134.84.143.177:foo:OK
> Tue Jul 27 12:42:44 2010:server3:WIRELESS:uofm_secure:134.84.143.177:foo:OK
> Tue Jul 27 12:42:57 2010:server3:WIRELESS:uofm_secure:134.84.143.177:foo:OK
> Tue Jul 27 12:43:09 2010:server3:WIRELESS:uofm_secure:134.84.143.177:foo:OK
> Tue Jul 27 12:43:21 2010:server3:WIRELESS:uofm_secure:134.84.143.177:foo:OK
> Tue Jul 27 12:43:31 2010:server3:WIRELESS:uofm_secure:134.84.143.177:foo:OK
> 
> Which usually results in no connectivity and an unhappy customer.  If the user kills their supplicant and starts over, usually it results in a normal exchange and things are good.  
> 
> Any ideas?
> 
> -- 
> Andrew D. Clark
> Network Operations Engineer
> University of Minnesota, Networking/Telecom Services
> 2218 University Ave SE
> Minneapolis, MN 55414-3029
> Phone: 612-626-4880
> 
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator



NB: 

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets), 
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.