EWC not resuming RADIUS auth requests after server starts responding again

  • 0
  • 1
  • Question
  • Updated 2 years ago
  • Answered
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.

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.
Photo of James A

James A, Embassador

  • 7,492 Points 5k badge 2x thumb

Posted 2 years ago

  • 0
  • 1
Photo of Raffi

Raffi, Employee

  • 1,598 Points 1k badge 2x thumb
Can you verify that the NTP on all the wireless controllers and NACS are configured properly and working?
Photo of James A

James A, Embassador

  • 7,492 Points 5k badge 2x thumb
Yep:
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
(Edited)
Photo of James A

James A, Embassador

  • 7,492 Points 5k badge 2x thumb
So I upgraded my NAC servers overnight, and the same thing happened. I had to reboot the EWCs before they would authenticate again.