Can’t Connect to This Network
We were in the stages of cleaning up configurations and preparing for customers to begin connecting to the new WLAN when I noticed that the LED on the Cisco 2802i AP on the workbench next to me was green indicating that there were no clients currently connected, even though the test laptop also right next to me should have been.
When trying to connect, the attempt went on for longer than normal, then culminated with an error message in the Microsoft Windows 10 system tray widget stating, “Can’t connect to this network.”
At the time, I was working with one of my customer’s system administrators to deploy the WLAN connection profile to all workstations on the environment via Microsoft Active Directory Group Policy. Our first thought was that the new policy may have caused the outage. He showed me where to find the system logs within Event Viewer on the workstation and they indicated that “There was no response to the EAP Response Identity packet.” Just to be safe, we unlinked the new group policy for the time being.
I proceeded to our Cisco Identity Services Engine (ISE) network access control (NAC) appliance which I found to be reporting “RADIUS Accounting-Request dropped” events with an accompanying reason for the failures stating “RADIUS Accounting-Request header contains invalid Authenticator field”. The NAC appliance also offered some advice for possible resolution, suggesting that the issue is most likely due to a RADIUS shared secret configuration mismatch.
Upon seeing this message, I thankfully recalled that a member of my customer’s network team had recently updated the RADIUS shared secrets. I validated this with him as well as ensured that he updated all entries on both ends, to which he concurred. Still, we were having an issue so the next step was to re-do his work.
Upon logging in to the Cisco 3504 wireless LAN controller (WLC), I happened to notice on the monitor page that the workstation was associated, but unable to complete 802.1X authentication. The WLC logs indicated that the RADIUS server was failing to respond to requests from the client, further nudging us in the direction of a shared secret mismatch.
I had personally updated all instances of the shared secret to the customer’s desired string on both the WLC and in ISE. Unfortunately, this did not resolve.
I spoke with the teams about any other recent changes. Sadly, reverting these changes did not yield resolution.
A capture using a protocol analyzer, Wireshark, revealed the beginning of 802.1X authentication that ended with an acknowledgement to an EAP Response packet holding the supplicant identity. This only further bolstered the suspicion in the validity of the shared secret.
I happened to recall, thinking back to recent NTP configurations, that certain devices in my customer’s environment did not appreciate some special characters in keys that were auto-generated by their Microsemi NTP server. The RADIUS shared secret that my customer had reconfigured on the WLC contained special characters whereas the one I had configured, which was only meant to be temporary until solution turnover, was very simple with just lowercase letters.
After reconfiguring the RADIUS shared secrets one more time using only lowercase letters, connectivity was restored. The lesson here was two-fold. It was a solid reminder that validation should occur both before and after changes. We also want to be careful as vendors may have differences in their implementations, such as in supported characters for keys.
