AW: AW: EAP-TLS Failed in handler question

Tue Dec 4 16:59:46 CET 2012

Hi!

I was still not able to get a trace on the client site, but I believe these debug log entries should help. This time I got the start packet and it is within some seconds that I get the 2 packet to the radius server and the State variable seems to be the same.

Ready to process requests.

rad_recv: Access-Request packet from host 10.xx.xx.5 port 54217, id=11, length=152

        User-Name = "host/xxxxxxxxxxxxx.local"

        EAP-Message = 0x02ff002101686f73742f4456542d303039363832322e7469726f6c2e6c6f63616c

        NAS-IP-Address = 10.xx.xx.5

        Service-Type = Login-User

        Calling-Station-Id = "xx-xx-xx-xx-xx-xx"

        NAS-Port-Id = "1:29"

        NAS-Port = 1029

        NAS-Port-Type = Ethernet

        Message-Authenticator = 0xd080844ef3e47a9bc21e8c848b5a8548

......

[eap] EAP packet type response id 255 length 33

[eap] No EAP Start, assuming it's an on-going EAP conversation

+++[eap] returns updated

++- else else returns updated

Found Auth-Type = EAP

# Executing group from file /etc/raddb/sites-enabled/default

+- entering group EAP {...}

[eap] EAP Identity

[eap] processing type tls

[tls] Requiring client certificate

[tls] Initiate

[tls] Start returned 1

......

Sending Access-Challenge of id 11 to 10.xx.xx.5 port 54217

        EAP-Message = 0x010000060d20

        Message-Authenticator = 0x00000000000000000000000000000000

        State = 0x642534cc642539e20b4be1e3ae0328c0

Finished request 62603.

Going to the next request

Waking up in 4.9 seconds.

rad_recv: Access-Request packet from host 10. xx.xx.5 port 54217, id=12, length=242

        User-Name = "host/xxxxxxxxxxxxx.tirol.local"

        EAP-Message = 0x02ff00690d800000005f160301005a01000056030150bd9377fb696c9f5eaedc568220f9aa35ab65930cf2232f4131c054b0562954000018002f00350005000ac013c014c009c00a003200380013000401000015ff01000100000a0006000400170018000b00020100

        NAS-IP-Address = 10.xx.xx.5

        Service-Type = Login-User

        Calling-Station-Id = "xx-xx-xx-xx-xx-xx"

        NAS-Port-Id = "1:29"

        NAS-Port = 1029

        NAS-Port-Type = Ethernet

        State = 0x642534cc642539e20b4be1e3ae0328c0

        Message-Authenticator = 0xeada93f9da1ca47a6f0325e8ad0414a9

.......

[eap] EAP packet type response id 255 length 105

[eap] No EAP Start, assuming it's an on-going EAP conversation

+++[eap] returns updated

++- else else returns updated

Found Auth-Type = EAP

# Executing group from file /etc/raddb/sites-enabled/default

+- entering group EAP {...}

rlm_eap: No EAP session matching the State variable.

[eap] Either EAP-request timed out OR EAP-response to an unknown EAP-request

[eap] Failed in handler

++[eap] returns invalid

There is no other packet between this two and only 5 seconds, server has not been restarted.

Robert

-----Ursprüngliche Nachricht-----
Von: freeradius-users-bounces+robert.penz=tirol.gv.at at lists.freeradius.org [mailto:freeradius-users-bounces+robert.penz=tirol.gv.at at lists.freeradius.org] Im Auftrag von PENZ Robert
Gesendet: Dienstag, 27. November 2012 17:38
An: FreeRadius users mailing list
Betreff: AW: AW: EAP-TLS Failed in handler question

> > With first packet I meant first packet the radius server saw in some time ... the switch forces a reauthentification every 2h

> A re-auth is a fresh EAP session. So even on a re-auth, the first packet

> would not have a "State" attribute, absent software bugs.

ok

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

> >

> > We're running Extreme Networks Switches with following timers set:

> >

> > configure netlogin dot1x timers quiet-period 30

> > configure netlogin dot1x timers reauth-period 7200

> We run SummitX edge, and when I've tested dot1x netlogin in the past, I

> haven't seen this issue. We've never widely deployed it, however, so

> it's possible there's an XOS bug where a small percentage of re-auths

> erroneously re-use the "State". You'd need to get a packet capture to be

> sure.

ok ... will try to get one .. is not easy ...

> > but reject means the switch sets the port to the guest vlan, and therefor the PC loses the connections ... is there a way to request a new full eap/tls handshake from the client?

>

> You're not understanding, or I'm not making myself clear.

>

> Suggestion: fire up wireshark, and take a careful look at a normal EAP

> authentication. You'll see that the first packet is an EAP-Identity

> without a "State" attribute, which the server responds to with an

> Access-Challenge containing the default eap type "start" payload, and a

> "State" attribute.

>

> Are you *absolutely sure* that these packets are really the first RADIUS

> packet in the auth/re-auth?

will check again and get back to you

> If you're sure, your problem seems to be that the correct first packet

> isn't being sent; the switch is just jumping straight in with the EAP

> payload *and* a "State" attribute. I am curious to know where it's

> getting that "State" attribute.

>

> The server source code assumes that a "State" attribute will be valid.

> There's no setting to "just accept it".

>

> Interestingly, I see the RADIUS RFC does actually allow clients to send

> a previous "State" if you send an Access-Accept with:

>

>   Termination-Action = RADIUS-request

> You're not doing that, are you?

no, I'm not

> No. As above, re-auths start new EAP sessions. You would only reject any

> EAP sessions that were in the *middle* of performing an auth, as the

> "state" would be lost across restarts. But this is a very narrow window.

so I would be best to set iptables to drop requests for 1min than restart the radius und remove the iptables rules? or can I set freeradius in a mode where is does not accept new sessions? and after 2 minutes I restart it? So that the switch is forced onto the other switch.

or what is the best practice to never have falls rejects?

-

List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20121204/abcdcde7/attachment-0001.html>