Wireless Access

I have doubt in regards with Campus AP coverted to Remote AP, why can't i use Remote AP in an enterprise network internally ?

Remote AP is basically a campus AP that can traverse a NAT boundary.  If you do not have a NAT boundary in your enterprise, there is no reason to use a Remote AP.  Campus APs with CPSEC can bridge SSIDs and wired interfaces, and if those are your reasons for using a remote AP, that functionality is available through a campus AP.

I've heard couple consultant saying that they don't usually enable CPSEC as they've had some issues before. Can't really remember what it exactly was, something to do with certificates probably :) Maybe something related to moving APs somewhere and something something not connecting... and they recommended using RAPs in the coupld places where we need like 5 APs per place and want to just bridge mode.

Any reason not to use CPSEC? Currently we have 1k+ APs without CPSEC so we would need to reboot them all after enabling CPSEC.

---

@pubjohndoe wrote:

I've heard couple consultant saying that they don't usually enable CPSEC as they've had some issues before. Can't really remember what it exactly was, something to do with certificates probably :) Maybe something related to moving APs somewhere and something something not connecting... and they recommended using RAPs in the coupld places where we need like 5 APs per place and want to just bridge mode.

 

Please get that consultant to post on here what his/her issue is so that we can get specifics.  "I heard" does not do us any favors here.

 

Any reason not to use CPSEC? Currently we have 1k+ APs without CPSEC so we would need to reboot them all after enabling CPSEC.

 

There is no reason Not to use CPSEC.  It is also designed to and will protect against management plane attacks on access points.

 

---

I think "There is no reason Not to use CPSEC" pretty much answers this :) If there were actual issues with CPSEC more people would've heard about those and there would be "...but if you're doing X then..."

I'll have to ask him if I see him in the near future. And will have to arrange some downtime to enable CPSEC as we have couple of those sites where we need local bridging.

CPSEC is enabled by default and has been for years now.  People who would want to decrease the initial time spent for when access come up disable it, but never re-enable it, so they cannot (1) Prevent unauthorized access points from connecting (2) Deploy A Bridged SSID within their Campus (3) Deploy a Bridged ethernet interface within their campus or (4) Protect against AP management plane attacks effectively.

Disabling CPSEC for anything besides testing purposes is a mistake.  Fortunately it can be undone.

---

@cjoseph wrote:

 

Disabling CPSEC for anything besides testing purposes is a mistake.  Fortunately it can be undone.

---

(Replying to old thread but as it was discussed here previously so if anyone finds this with search etc..)

I heard the idea behind disabling CPSEC was that there is going to be extra work or something involved if a controller breaks and needs to be replaced.

Is there any truth to it even if using a single MM manged controller and not a cluster? What happens if you need to replace the controller and have all the APs boot to the same controller IP, but I guess some certificates are different in that case? Does the new controller just issue new certificates?

The new controller issues new certificates.  CPSEC on does add a reboot or two as a result.  I would just type "show whitelist-db cpsec" to monitor the status of your access points.  This would only be a onetime event, however.