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@lists.freeradius.org [mailto:freeradius-users-bounces+robert.penz=tirol.gv.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