AW: AW: EAP-TLS Failed in handler question

[PENZ Robert]

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