On 21/11/12 12:00, PENZ Robert wrote:
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.
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.
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? 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?
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?
no the server is running for > 10 days
but if I would restart the server I would reject all clients to the guest vlan on reauthentication after that ... that can't be the designed way.
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.