Six FortiAPs Stuck in Discovering After Core ACL Change
A campus has 26 FortiAP 231F units managed by a FortiGate 200F running FortiOS 7.6. APs are on VLAN 300 with a DHCP scope on the FortiGate and CAPWAP to 10.0.0.1. After a core switch maintenance window, 6 APs on the second floor stay in discovering state. They receive 10.300.x addresses, can ping the gateway, and can resolve DNS. The FortiGate sees no WTP entries for their MAC addresses. The core switch ACL between VLAN 300 and the FortiGate permits DHCP, DNS, and ICMP only; APs on VLAN 10 work. The DHCP scope for VLAN 300 has option 138 set to 10.0.0.1. A new ACL was applied to VLAN 300 that blocks UDP 5246-5247 but permits TCP 5246.
1. Where in the CAPWAP join sequence would you focus, and what evidence supports that?
Read the worked answer
Focus on CAPWAP discovery and control establishment, not on wireless client authentication or SSID configuration. The APs have valid addresses, gateways, and DNS, and they can ping the FortiGate, so Layer 3 reachability and DHCP are working. They remain in discovering state and the FortiGate has no WTP entries, which means the APs are not completing the CAPWAP control exchange with the wireless controller. APs on VLAN 10 work, so the FortiGate controller, certificates, and global wireless configuration are probably healthy.
The ACL is the strongest suspect. CAPWAP uses UDP 5246 for control and UDP 5247 for data. An ACL that permits DHCP, DNS, and ICMP but blocks UDP 5246-5247 allows the AP to boot and get an address but prevents the join. DHCP option 138 is correct, so the APs are likely trying the right controller and being filtered. Confirm with a packet capture on the FortiGate for UDP 5246 and 5247 from the VLAN 300 AP addresses and with ACL hit counters on the core switch.
2. What commands or tools would you use to confirm, and what exact ACL change is needed?
Read the worked answer
On the FortiGate, run a packet capture for UDP ports 5246 and 5247 while an AP is booting, and check the wireless controller WTP table for the AP MAC addresses. On the AP console, use the CAPWAP or wireless controller debug output to see whether discovery reaches the controller and where it stops. On the core switch, inspect the ACL hit counters and the VLAN 300 interface statistics. If the capture shows no CAPWAP packets arriving from VLAN 300 but ICMP succeeds, the ACL or an intermediate policy is dropping them.
Change the ACL to permit UDP 5246 and 5247 from the VLAN 300 AP subnet to 10.0.0.1 and the return traffic. Keep DHCP and DNS permitted. If the ACL is applied in both directions, ensure the return path is also allowed. Do not open all protocols; restrict the rule to the AP subnet and the controller address. After the change, reboot or power-cycle one AP, confirm it appears in the WTP table, and then verify the remaining APs join.
3. After fixing the ACL, four APs join but two remain in discovering. What would you check next and why?
Read the worked answer
Since four APs now join, the global ACL and controller reachability are fixed; the remaining fault is per-AP or per-port. Check the two APs' switch ports for the correct native VLAN 300, PoE status, and whether the AP management traffic is tagged or untagged as expected. Confirm their DHCP leases and option 138 values, and check whether they received addresses from the correct VLAN 300 scope rather than a different scope. A native VLAN mismatch can let the AP get an address through a helper but prevent CAPWAP from reaching the controller.
Use the AP console to see whether it is sending CAPWAP discovery and to which address, and capture traffic on the access switch port to confirm the packets leave. Check the FortiGate WTP table for the AP MACs and any authorization or certificate errors. If the APs are on a separate floor switch, verify that switch's uplink ACL and trunk allowed VLANs. Finally, compare firmware and AP profile assignment with a working AP; a stale static controller setting or a local configuration difference can keep an individual AP in discovering after the network path is repaired.