Skip to main content
pjang
Staff & Editor
Staff & Editor
February 18, 2026

Technical Tip: Unauthorized FortiAP 'FP221E' unexpectedly appearing on FortiGate's Managed FortiAPs page

  • February 18, 2026
  • 0 replies
  • 3953 views
Description

This article describes an observed behavior where the FortiGate may show a new and unexpected FortiAP entry under WiFi & Switch Controller -> Managed FortiAPs that does not correspond to any FortiAPs deployed to the environment. The following symptoms have been observed on the FortiGate when this scenario occurs:

  • Under the Managed FortiAPs page, a new FortiAP entry is present that may be labelled 'FP221E' (though it may also have another name/serial number that does not correspond to any FortiAPs expected on the network).
  • FortiGate HA clusters will also show as out-of-sync, with mismatched checksums being observed under the wireless-controller.wtp sub-section (aka config wireless-controller wtp).
  • Security Fabric Connection is enabled on externally-accessible interfaces on the FortiGate (e.g. WAN interfaces).
Scope FortiGate, FortiAP.
Solution

As a primer, the FortiGate is able to discover FortiAPs for management when they send a CAPWAP Discovery Request message towards the FortiGate. In order to accept and process this discovery packet, the FortiGate must have Security Fabric Connection enabled on the network interface that actually receives the traffic (physical interface, VLAN, aggregate, etc.). This setting has also been referred to as 'CAPWAP' and 'FortiTelemetry' in FortiOS versions before v7.x.

 

GUI:

 

AdminAccess_GUI.png

 

CLI:

 

config system interface

    edit "port1"

        set allowaccess fabric

    next

end

 

Observed issue:

At the time of this writing, it has been observed that external hosts on the Internet are sending spoofed CAPWAP Discovery Request packets across the Internet towards public IPs associated with the FortiGate, and these spoofed packets are structured similarly to how a real FortiAP would construct these packets.

If a FortiGate receives this packet on the WAN interface and that interface also has Security Fabric Connection enabled in the Administrative Access settings, then the result is that a discovery entry is created for that FortiAP on the FortiGate.

 

For example, under Log & Report -> System Events -> WiFi Events, unexpected 'ap-add' are seen from unknown FortiAP serial numbers.

image.jfif

 

Additionally, administrators of FortiGate HA clusters will likely find that this new FortiAP entry is only present on one of their FortiGates (typically the current HA primary unit) and that the HA cluster is reporting as out-of-sync because of this difference in the configuration.

 

FP221E_Example.jpg

 

In some cases, the GUI may show an unknown FortiAP that has not been authorized, and it cannot be removed through either the CLI or the GUI. To resolve this issue, reboot the FortiGate to clear the unknown FortiAP entries. For more information, refer to: Troubleshooting Tip: How to delete unknown FortiAP that appears in FortiGate GUI 

 

Important notes:

  • This Managed FortiAPs entry only signifies that a FortiAP has been discovered. Unless administrators also enable auto-auth-extension-device on the interface (which is CLI-only and disabled on all interfaces by default), the FortiGate will not accept this FortiAP for management until an administrator explicitly chooses to accept/adopt it.
  • Even though the HA cluster is reporting as out-of-sync, remember that this status only indicates the cluster members have differences between the saved configurations. HA synchronization functionality is still working between cluster members (so sessions and the rest of the configuration is still being synced), but it is just this sub-section that is not able to be synced at this time.

 

Recommendation:

Generally speaking, best practice is to only enable this setting on interfaces that are used to manage company-owned Fortinet devices (such as FortiAPs and FortiSwitches), such as internal AP management VLANs or FortiLink interfaces. Therefore, the recommendation is to disable Security Fabric Connection on all interfaces that are not specifically expected to manage a Fortinet extension device. Treat the Security Fabric Connection setting with the same weight as other admin access functions like HTTPS and SSH, though if it must be enabled on a WAN interface to support a business use case, then see the additional notes section further below.

 

Once Security Fabric Connection is disabled on the WAN-facing interfaces, it will no longer be possible for external actors to trigger the creation of these unexpected FortiAP entries. From there, simply delete these entries from the FortiGate using the GUI or the CLI (this will also resolve the HA out-of-sync issue related to this scenario):

 

GUI: Navigate to WiFi & Switch Controller -> Managed FortiAPs, select the entry (or right-click on the entry), and select Delete.

 

CLI: Navigate to config wireless-controller wtp and delete the excess entries as demonstrated below (if the entry name is different, then adjust accordingly).

 

FortiGate # config wireless-controller wtp

FortiGate (wtp) # show

config wireless-controller wtp
    edit "FP221E"
        set uuid f22d6f74-0752-51f1-b78b-74771f5ab1d1
        set admin disable
    next
end

FortiGate (wtp) # delete FP221E

FortiGate (wtp) # show

config wireless-controller wtp
end

FortiGate (wtp) # end

 

Additional Notes:

Some use cases may require the FortiGate to accept FortiAP management traffic on Internet-facing interfaces. For example, FortiAPs might be deployed to remote sites and connect back to a main FortiGate for both centralized management and encrypted access (see also Remote WLAN FortiAPs and Deploying Remote APs).

 

For situations like these, it may not be possible to disable Security Fabric Connection; in this case, consider the following options for tightening access to this feature:

  • For fixed deployments (e.g., FortiAPs at branch offices or home offices), consider adding Local-In Policies on the FortiGate to restrict CAPWAP traffic to a specific allow-list of remote public IP addresses (see also: Local-in policy).
    This allows the FortiGate to only accept CAPWAP traffic from known hosts and drop it from all unknown hosts.
  • For non-fixed deployments (e.g., 'road warrior'/travelling workers), consider switching to a remote access VPN solution such as dial-up IPsec with FortiClient (for example: Technical Tip: FortiGate IPsec dial-up IKEv2 SAML-based authentication with FortiAuthenticator as IdP).
  • For sites that have both FortiGates and FortiAPs (e.g., branch FortiGate and FortiAP managed by main FortiGate), consider having the FortiAP access the central FortiGate over a protected channel rather than directly over the Internet, such as with an IPsec site-to-site tunnel between the branch and main FortiGate.
  • If CAPWAP Discovery Requests are still being received and it is not possible to filter them out via the methods above, it may still be advisable to change the FortiAP entry from Discovered to Rejected, as this will signal to other administrators that this FortiAP entry is not and should not be authorized.
    • To do this, select the entry under WiFi & Switch Controller -> Managed FortiAPs (or 'right-click') and select Authorization -> Reject. This can also be done from the CLI, as shown below.
    • Note that even when the FortiAP entry is set to rejected, the FortiGate will still reply to incoming CAPWAP Discovery Request messages with a corresponding CAPWAP Discovery Response when Security Fabric Connection is enabled on the interface. This is expected behavior.

 

config wireless-controller wtp
    edit "FP221E"
        set admin disable
    next
end

 

Related documents:

FortiOS Best Practices: Hardening.

Technical Tip: How to reject a CAPWAP discovery request coming from an unknown Access Point

Technical Tip: Explaining FMG-Access on FortiGate Interface Settings