EAP-TLS Failed in handler question

[Phil Mayers]

On 11/19/2012 08:23 AM, PENZ Robert wrote:
>
> My first question is, how can I decode a EAP-Message from the debug

Wireshark, or read the EAP RFC and decode it manually (see below)

> log to check if the request is itself ok. Here is first packet from

No, this is *not* the first packet, because it has a "State" attribute, 
which is only present in 2nd and subsequent packets of the EAP exchange.

The reason you're getting the error message is that the "State" 
attribute is unknown, so FR can't proceed with the EAP session and has 
no choice but to drop it.

Check you haven't reduced the "timer_expire" value in eap.conf to a 
too-low value.

How many FR servers do you have serving this NAS? Is it possible the NAS 
is sending packets in a round-robin fashion (which is bad) which is why 
you're seeing a packet for which you don't have State?

I guess it's possible something is mangling the State attribute from the 
previous packet (which is *actually* the first packet).

Otherwise, the client or NAS is doing something odd.

> this client in some time, and it already generates the error. But the
> same client worked before and after it for days without a problem:

It *could* be that the client just got stuck and is responding (very) 
late. But I'm quite surprised the NAS didn't timeout the EAP auth before 
that.

>
> rad_recv: Access-Request packet from host 10.xxx.xxx.4 port 44519,
> id=151, length=244 User-Name = "host/xxxxxxxxxxxxx.tirol.local"
> EAP-Message = 0x02ff00690d800000005f160301005a01
>

Ok so this says:

02 - eap response
ff - eap ID 255 - bit odd..
0069 - length in hex
0d - eap type 13 (EAP-TLS)
80 - eap TLS flags = length included
0000005f - tls length
160301 - TLS packet 0x16==22==handshake record, version 3,1 (TLS 1.0)
005a - record length
01 - handshake=client hello

etc. etc.

So, it's the start of an EAP-TLS exchange, but as above, it's *not* the 
first packet. If you start a tcpdump on the server, you'll see how this 
works:

C: Access-Request, no state, EAP-Identity=abc
S: Access-Challenge, state=xxxx, EAP-TLS blah
C: Access-Request, state=xxxx, EAP-TLS blah

i.e. the NAS has to reflect the "State" back to FreeRADIUS on each 
packet. Something is interfering with that, or erasing the "State" at 
your end (a timer or restart).

> rlm_eap: No EAP session matching the State variable

See?

> Invalid means I return a reject ... should I return something else?

No.

> Is this a client problem or a misconfiguration on my part?

It's probably a client or NAS problem, unless you've set timer_expire 
too low.

However: I guess this could also happen right after the server is 
restarted. Could that be it - is a cron job restarting it maybe?