Wireless Access

I'm trying to configure a AP61 as remote AP with the old username/passwd method. I'm doing this on a controller with only the base license so no toying around with my roles. This remote AP then connects over the LAN to the controller. 

Reasoning is to get a bridges SSID without enabling CPS on the controller

I've configured the vpn settings, created a local-userdb user and provisioned the AP with those settings.

After provisioning the AP does not show up in the database but it does not reboot at all either. I do not have any ipsec or isakmp sa's for this rap though.

Looking at the datapath I can see the 4500 from ap to controller fine, but the reverse direction (controller > AP) has a Y flag (no syn).

There is only a single router between rap and controller without any ACL or firewalling. A traceroute or ping works fine in either direction.

What is going wrong here? Anybody got a clue?

I would type "show log security 50" to see if there are any errors.  That is my first guess based on the information you submitted.

Nothing regarding this ap in the security (or any other) log I'm affraid.

Even the ap-debug I configured only lists a "<INFO> |stm|  AP 6c:f3:7f:c4:5a:6b is down" after the provisioning message there. No additional entries even after rebooting half a dozen times.

Okay.  Turn on the debugs below and try "show log security 50" again.

config t
logging level debugging security subcat ike
logging level debugging security process aaa
logging level debugging security process authmgr
logging level debugging security subcat l2tp
logging level debugging security subcat vpn

logging level debugging security process l2tp

but still nothing in there. Searched both for ip and mac-address of the remote-ap and did a scan to find anything usefull.

Can you try a different AP besides an AP61?  That would eliminate any AP-specific issues.  I cannot say that I have tried configuring an AP61 as a RAP since the 5.x, and it is not very common, so it is entirely possible that there is a bug, due to the fact that it is something that is not seen often.  Please try a different model of access point as any type of RAP to confirm your configuration is working.

Actually did that already.. used a ap61, ap68 and now an ap104.. all the same.

This is actually on a new 7240 controller (v6.3.1.7) replacing and old M3 (v6.1.3.9) as master.

On the 7240 I have this issue, on the old master I don't. Double and triplechecked my config so I'm leaning towards bug too :(

I need this rap working before I can rejoin the M3 as local and get my redundancy back in order though.

Did you configure the AP104 as a cert-based RAP?  If there are any crypto issues it should have showed up in the security log if you enable the debugs that I pasted into the post above.  In addition, you should connect to the AP console of the 104 to see if anything shows up.  There are 104s and 105s that work as cert-based APs on that code and on that platform.

No, was trying to get it back as it was so configured the ap104 also with username/passwd. But good idea.. let me try that before wasting even more time on this.

Nothing shows up on the AP console by the way. It finishes its boot 

shutting down watchdog process (nanny will restart it)...
 
        <<<<<       Welcome to the Access Point     >>>>>
 
~ #    

 and then just sits there.

When you do  a "printenv" at the apboot> prompt, do you see the master ip address and the fact that it is a remote AP and PSK configured?

Euhm,

can I actually bring up an ap-105 als certificate rap without control plane security on?

---

@cjoseph wrote:

When you do  a "printenv" at the apboot> prompt, do you see the master ip address and the fact that it is a remote AP and PSK configured?

 

---

yes

num_ipsec_retry=85
name=6c:f3:7f:c4:5a:6b
group=T-RAP
master=134.159.249.246
gatewayip=134.159.254.254
netmask=255.255.255.0
ipaddr=134.159.254.151
ip6prefix=64
dnsip=134.159.252.201
domainname=domain.tld
serverip=134.159.249.246
a_ant_gain=aa90502deebe0113cbdeed5b5164f6f31921113570002x002
g_ant_gain=aa90502deebe0113cbdeed5b5164f6f31921113570002x002
ap70_ext_ant=1
a_antenna=0
g_antenna=0
ikepsk=5BB274CC4146640624C7F96F5D782678FB2B0FC06D2106B747053EFCCED0E7BC
papuser=remoteap-user
pappasswd=29432BB9D17C5680C1BEB46E0158BB47AB256E59DF96C0E924A21CE06A04ECB4

The printenv looks fine.

RAPs do not depend on control plane security, so you can bring up an AP105 without it.

Which instructions are you using to configure the controller for the AP61?  Did you configure a VPN pool?

The reason why they switched to cert-based raps in the first place is that the configuration for non-cert-based RAPs required too much configuration.

How exactly?

I configured the RAP whitlist (thought this was CPS only though) with the ap-104 mac address.

Then purged the ap-104 and reprovisioned it as rap with certificate. Nothing other than that.  That's it?

Should be because my RAP is finally up and running!

Good to know I can use the certificate based RAPs without control plane security. 

 So not with an AP61 but an AP105.. I'm happy enough with that. 

Thanks!

Go figure.. ther AP105 with cert auth also stopped working after upgrading to 6.3.1.8.

Now both methods fail for me.  Working with TAC to get it resolved.

FYI: remote ap issues on 6.3.1.8 controller appeared related to centralized licensing.

The controller that the AP's connected to had no licenses of its own (only licenses from the pool). This caused the RAP's (and ONLY the RAP's) to fail due to missing licenses.

We did not have this issue in 6.3.1.7, so sofar only 6.3.1.8 seems affected.