I had cause to setup a Remote AP to my home lab. This was done hastily and without adequate testing. It turned into a bit of a fight to get it working, but why?..

There are many and varied reasons why a RAP might not work, I’m only going to focus on the specific issues I saw. The symptoms were that, ultimately, the RAP did not come up.

Using the command: show crypto debug event-logger
I could see the IKE negotiated and the tunnel come up, then almost immediately it went down. No other errors were logged.

On factory resetting the AP and then trying to configure again, I saw the same behaviour only this time the tunnel stayed up long enough for the AP to download its software, but then on reboot it would make the initial connection, then drop it.

The environment is AOS 8.10 with non-clustered controllers managed by a virtual mobility conductor.

There were two issues in my case.

Issue 1 – The AP Group LMS settings had the internal VRRP address of the controller. Although the RAP was provisioned to the public IP (NAT’d) I suspect it was also trying to build a tunnel to the LMS IP, which failed, at which point the AP gave up and rebootstrapped. I say I suspect this, I didn’t have the tools available for a packet capture to see what was happening but this fits with experiences shared on the Airheads forum.

Issue 2 – This is what I ran into when factory resetting the AP and trying to re-add it as a RAP. The AP was in the RAP approval list with a specific AP-group. After reset it was no longer provisioned to this group so didn’t come up.

To fix it: Here are the steps I followed, I’m not sure all of this was necessary, it was a process of elimination to try and get things working.

The AP was factory reset – this is an Instant AP so then needed to be converted to RAP mode. This was successful and the AP downloaded its software from the controller and then we ended up at issue 2.

To fix this, the RAP approval list was updated to allow the AP to use the default AP-group. At this point the AP came online.

The AP was provisioned to the desired AP group. At which point we were back at issue 1.

To fix this, the LMS entry was removed from the AP-group and the AP environment variable referencing the internal IP address was removed in ap-boot via a console cable. This last step wouldn’t have been necessary if I’d spotted the LMS entry before re-provisioning the AP.

Finally…. it works.