Wireless Access

Hello All,

I had 2 RAP-2WGs working a few weeks ago and I just noticed one of the RAPs wasn't working anymore.

It just wouldn't broadcast the SSIDs configured on the AP Group it's associated with while the other was working.

Been working on this and I still couldn't get it to work. I had to engage Aruba Support for this.

After an hour troubleshooting, we decided to look into the L3 Authentication Tab on the Controller. Then reference the VPN Authentication Profile. We noticed that the Default RAP Group's Server Group association was set to "Default" which was okay.

However, when we look at the Server Group Default configuration was not configured or associated to any Server.

Now, I confirmed that my RAP was configured on the RAP Whitelist whcih was configured for the RAP AP Group. Why would my RAP stop working while the other RAP worked fine.

I got it working by configuring the Server Group Default profile to be associated to the Internal Server. This I found strange.

It has been working for over 2weeks and I now had to configure this to get my RAP to work. Even when, one other RAP was working just fine before I made this change.

Any logical ideas on what could have been the issue? Should the Server Group (on the VPN Authentication Profile for the DefaultRAP Group) been associated to the Internal Server all this time?

This was supposed to be a Zero Touch Integration.

For zero-touch provisioning, the RAP whitelist is used for authenticating the RAPs. When zero-touch provisioning is used, the authentication server can be only the internal database of the controller. This is because, when a RAP that is configured for zero-touch provisioning connects to a controller it presents a certificate to the Aruba controller ( TPM based certificate) as apart of the IKE authenetication. The Aruba controller validates this certificate and extracts the certificate comman name, which is nothing but the mac address of the RAP. Now for the IKE-XAUTH authetication, the controllers authenticates this mac address (i.e. the certificate Common name) against the LocalDB-AP. The LocalDB-AP is the RAP whitelist which is part of the internal server. If an external authentication server is used then zero-touch provisioing will fail. Currenlty, external server can be used to authenticate only the RAPs that are provisioned using PSK.

Now, getting to why it was working for the past few weeks and not now question. At factory default, the default server group of the Aruba controller points to the internal server. it is possible that you or someone else might have deleted the internal server from the default server group in the past few days. After this happened, your other RAPs might have not rebooted except for the one that had issues. All the RAPs that didn't reboot didn't go through the authentication process again and worked fine. The RAP that had issues rebooted and  could not get authenticated (The RC_ERROR_IKE_XAUTH_AUTHORIZATION_FAILED error occurs only when the RAP certificate common name authentication against the RAP whitelist fails).  I am not saying that this is what exactly happened but this is very possible.

Regards,

Sathya

Thanks Sathya.

It makes a whole lot of sense.

Anyway, will keep an eye on it next time.