cancel
Showing results for 
Search instead for 
Did you mean: 

client roaming to prefered radio caused radius authentication event which failed

client roaming to prefered radio caused radius authentication event which failed

M_Nees
Contributor III
Currently i have a very strange problem.
We use EAP-TLS 802.1x Authentication for a internal SSID for notebooks. EWC is installed at the headquarter. 2x AP 3705 installed on the affected branch - we use V9.21.07. NAC Gateway 6.2.0.x installed also in the headquarter and is the RADIUS proxy to the NPS on the Windows AD 2008 Server. This working well over the last years.
Now we change the WAN connection of this branch from MPLS to VPN with IPSec. After this change a lot of internal WLAN clients which connected before without problems are rejected from the NAC Gateway. All other branches working well. At wired switches we use only MAC Auth which is also not affected.

Error:
802.1x (identify) - Authentication became stale

After some troubleshooting i realized that if the client roam within the AP to its prefered radio for that roaming event a radius request is triggered. The the first request (to the first radio) is always possitive (accepted) and then the AP internal switch to the prefered radio triggers a RADIUS request which is always rejected - with the above error message.

For a temporary solution i disable radio 1! And then all client can login without problems!

This is very strange.

First question:
Why do an switch from radio 2 to radio 1 trigger a radius event. Can i disable this new login request in the AP / EWC config?
Second Question:
If this request is needed why does it become stale and will be rejected?


Thanks for any advices.
Regards
22 REPLIES 22

Additionally you write that authentication works fine with one radio disabled.
--> i believe that because there was an accept in NAC Manager GUI.
This was a mistake by me.

M_Nees
Contributor III
Hi Folks,

this problem is still unresolved!!

GTAC tell me this solution:
https://gtacknowledge.extremenetworks.com/articles/Solution/Apple-clients-take-very-long-time-to-get...

i get a wireshark trace of a rejected end-system which emphases this guess:
NPS is not possible to bring the Server certificate to the client! (and then the request is rejected)

The problem of the above solution is that it only works if NPS will accept the RADIUS Request. So clients are still rejected (because of too big MTU). The reduced Framed-MTU will never reaches the problematic clients!

If i debug the RADIUS request on NAC Gateway i see the Framed-MTU value is set to 1400 (Request from EWC).

Can i change this value on the EWC?

My first guess is this is calculated based on the used AP-MTU Size. But after i changed AP MTU to 1300 is see that the Framed-MTU does not changed (1400). So this seems to be fix in the EWC Config. But from my point of view this should be calculated in conjuntion of the set AP MTU!

Regards

M_Nees
Contributor III
Because we have a downtime based on this issue i open a GTAC Case to solve that - 01232203.

Gareth_Mitchell
Extreme Employee
Matthias

Do you have AP secure tunnel and is NAT involved?

-Gareth
GTM-P2G8KFN