EWC not resuming RADIUS auth requests after server starts responding again


One of our NAC servers was having a problem authenticating users recently:

Wed Feb 1 20:17:05 2017 : Error: (10012414) [etsnac] The AAA server response ID: 10012414 had an unknown command: 35.

[/code]so no-one could get on the wireless. I rebooted the appliance and it came back fine. The wireless controller however stopped sending it RADIUS authentication requests, despite it being the only RADIUS server configured for the VNS. If I added the secondary NAC server to the VNS, that one worked fine, but after removing it, the wireless controller still wouldn't talk to the original NAC server. In the end I had to reboot the wireless controller and then everyone was good again. Is there some way I can tell the EWC that a RADIUS server is good again? Or see what it was stuck on?

As for why we have two NAC servers but only one configured in the VNS, iOS somehow knows they are different (despite having the same SSL certificate) and requires going to settings tapping on the wifi network and accepting the certificate when you roam to an AP that's using the second NAC server before it will connect. Has anyone managed to configure two NAC servers such that iOS can't tell the difference?

The correct way to do this in iOS/macOS is create a wifi configuration profile containing the CA that's signed the RADIUS server certificate, then it will trust both servers. We do this for our Macs, but it's not convenient to do this with iOS since you generally need wifi connected to install profiles, amongst other reasons.

3 replies

Userlevel 4
Can you verify that the NTP on all the wireless controllers and NACS are configured properly and working?
Raffi wrote:

Can you verify that the NTP on all the wireless controllers and NACS are configured properly and working?

Yep:
[/code]root@antennae-a:/var/log# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*203.135.184.3 ( 203.135.184.123 2 u 3 64 7 1.072 3.613 2.672

root@netsight.ccgs.wa.edu.au:/usr/local/Extreme_Networks/NetSight/appdata/logs$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*10.20.0.1 203.135.184.123 2 u 397 1024 377 0.991 -0.247 0.205

root@schwarzschild.ad.ccgs.wa.edu.au:/var/log$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*10.20.0.1 203.135.184.123 2 u 261 512 377 0.959 -0.091 0.138[/code]
Raffi wrote:

Can you verify that the NTP on all the wireless controllers and NACS are configured properly and working?

So I upgraded my NAC servers overnight, and the same thing happened. I had to reboot the EWCs before they would authenticate again.

Reply