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?