A controller-based AP in a municipal annex powers up but never joins the downtown wireless controller. Firewall logs show the AP's CAPWAP/control traffic to the controller is blocked. What technician awareness applies?
Select an answer to reveal the explanation.
Short Explanation
A lightweight AP without a path to its controller is like a remote worker locked out of HQ VPN—lights may be on, but it never really checks in. Open the control path or that AP stays a brick in join terms.
Full Explanation
A controller-based AP in a municipal annex that powers up but never joins the downtown wireless controller—with firewall logs showing CAPWAP or control traffic blocked—illustrates that controller-based APs require IP reachability on the control path to their controller in order to join and operate as designed. Without a working control channel, the AP cannot complete join, download configuration, or function as a managed campus radio. Firewall policy between annex and downtown must allow the required controller protocols.
Controller-based APs cannot fully serve clients as designed when the control path stays blocked forever. Blocking CAPWAP affects AP join state, not only guest captive portals. The AP should not ignore firewall policy and fall back to ad-hoc IBSS mode automatically as a substitute for controller join.
Exam caveat: treat CAPWAP/control reachability as a hard dependency for controller-based APs during annex troubleshooting. Operational check: from the AP subnet, verify IP reachability and permitted ports/protocols to the controller addresses, adjust firewall rules with change control, and confirm the AP transitions to joined status on the WLC. After firewall changes, re-validate join from a cold boot so the annex AP recovers cleanly without manual console intervention.