NSE6 Part 10: FortiAP Rogue Detection, Wireless IDS, Mesh, and Troubleshooting

9 June 2026 NSE6Fortinet

The final third of the FCA-FAP exam covers threats to the wireless environment and deployment patterns beyond the basic AP-to-client model. Rogue detection, wireless IDS, mesh, and remote APs are all scenario-based on the exam — expect questions about what a specific WIDS event means, when to use mesh vs a cable run, and how to interpret diagnostic output from a broken AP.

WIDS — Wireless Intrusion Detection System

What WIDS monitors

A FortiAP radio in monitor mode (or as a background task alongside client-serving) passively scans the RF environment, capturing 802.11 management frames from every device it can hear — including devices not associated to your network. This data feeds the WIDS engine.

WiFi & Switch Controller > WIDS Profiles

Rogue AP classification

ClassificationDescription
RogueAn AP that is connected to your wired network but is not managed by your FortiGate WLC. Most dangerous — it is a bridging point from the air to your internal VLAN.
NeighbourAn AP that is not connected to your network. A neighbour AP in the adjacent office building. Not a threat — just noise.
UnclassifiedNewly discovered AP that hasn’t been classified yet.

On-wire detection: FortiNAC or FortiGate can correlate the BSSID (MAC address) of an AP seen over the air with the switch port MAC table. If the AP’s MAC appears in the switch table, it is connected to your wired network — classifying it as a rogue.

Rogue AP suppression

Suppression (also called containment) sends deauthentication frames to clients of a rogue AP, preventing them from maintaining an association. The AP itself cannot be “shut off” by radio — you need to find and disconnect it physically.

Legal consideration: In many jurisdictions, sending deauthentication frames to a device you don’t own is illegal. The exam knows this — expect a question about whether to enable suppression. The recommended answer is: classify and locate the rogue physically; only use suppression if legally permitted and as a last resort.

config wireless-controller wids-profile
  edit "corp-wids"
    set rogue-scan enable
    set ap-auto-suppress disable    # do not automatically suppress
  next
end

SSID spoofing detection

An attacker runs a rogue AP with the same SSID as your legitimate network (an “evil twin”). WIDS detects this because the evil twin has a different BSSID. If two BSSIDs are broadcasting the same SSID and only one is authorised, the other is flagged.

Wireless IDS Signatures

WIDS signatures detect specific attack patterns in 802.11 management frames:

SignatureWhat it detects
Deauthentication floodAttacker sends large volumes of forged deauth frames, disconnecting legitimate clients (DoS). PMF (Protected Management Frames) mitigates this.
Disassociation floodSimilar to deauth flood — spoofed disassociation frames.
Beacon floodAttacker broadcasts hundreds of fake SSIDs, overwhelming wireless clients and APs.
Probe response floodFlood of probe responses to confuse clients.
EAPOL floodFloods EAPOL-Start frames at an AP, exhausting authentication state table.
Ad-hoc networkA device is broadcasting as an ad-hoc (IBSS) network rather than infrastructure — indicates a client configured as a hotspot.
Weak WEP IV detectionDetects WEP IV reuse, indicative of WEP cracking in progress. WEP is deprecated — this is a legacy signature.
KRACK (Key Reinstallation Attack)Detects anomalous retransmission of handshake message 3 (4-way handshake nonce reuse). Indicates an attacker is attempting WPA2 key reinstallation.
config wireless-controller wids-profile
  edit "corp-wids"
    set rogue-scan enable
    set deauth-detection enable
    set deauth-frame-threshold 10     # events per second before alert
    set eapol-flood-detection enable
    set eapol-flood-threshold 20
    set ad-hoc-detection enable
  next
end

Assign the WIDS profile to the radio in the WTP profile:

config wireless-controller wtp-profile
  edit "FAP-432F-profile"
    config radio-1
      set wids-profile "corp-wids"
    end
  next
end

FortiAP Mesh

What mesh is for

Mesh allows a FortiAP to connect to the FortiGate WLC wirelessly rather than via a wired Ethernet uplink. Useful when:

  • Running cable to an AP location is impractical (outdoor, historic building, warehouse).
  • A cable run is expensive relative to the cost of the wireless backhaul.

Mesh topology

FortiGate --- (wired) --- Root AP
                              |
                          (wireless backhaul)
                              |
                           Leaf AP
                              |
                          (wireless backhaul — 2nd hop)
                              |
                           Leaf AP (2nd hop)
  • Root AP: Has a wired Ethernet uplink to the network. Bridges between wired and wireless backhaul.
  • Leaf AP (mesh AP): No wired uplink. Connects to the network via a CAPWAP-over-wireless backhaul to a root AP (or another leaf AP).

Performance degradation per hop: Each wireless hop halves effective throughput (the radio uses half its airtime forwarding backhaul traffic). Keep mesh hops to 1–2 maximum for acceptable performance.

Backhaul SSID

The backhaul SSID is a dedicated SSID used only for AP-to-AP mesh communication — clients do not connect to it. It should run on 5 GHz (more bandwidth, less interference) and use WPA2-Enterprise or WPA3-SAE for security.

config wireless-controller vap
  edit "mesh-backhaul"
    set ssid "corp-mesh-backhaul"
    set broadcast-ssid disable       # clients can't see or connect to it
    set security wpa2-only-enterprise
    set mesh-backhaul enable
  next
end

Configuring mesh on the WTP profile

config wireless-controller wtp-profile
  edit "FAP-231F-mesh"
    set ap-handoff enable
    config radio-1
      set band 802.11ax-5G
      set mode ap
      set mesh-backhaul enable
    end
  next
end

On the leaf AP’s WTP object:

config wireless-controller wtp
  edit "FAP231FTF00002"
    set mesh-bridge-enable enable
    set mesh-eth-type 1              # 1 = upstream (leaf AP looking for root)
  next
end

Remote AP / OfficeExtender

FortiAP-U series models (Universal) support a VPN tunnel from the AP back to HQ FortiGate. This extends the corporate wireless network into remote locations (home offices, small branch sites) without requiring a FortiGate at the remote site.

Architecture

Home User's ISP --- FortiAP-U (OfficeExtender) --- VPN tunnel --- HQ FortiGate
                          |
                    Local SSIDs:
                    - Corp SSID (tunneled to HQ)
                    - Personal SSID (local internet breakout)

Split tunnel

The AP handles two types of traffic:

  • Corporate traffic (Corp SSID): Encapsulated in the CAPWAP/VPN tunnel back to HQ FortiGate. FortiGate applies UTM policy. This traffic takes the WAN path to HQ.
  • Personal traffic (personal SSID or internet-direct): Bridged locally through the AP’s Ethernet uplink to the home internet. Does not traverse the VPN.
config wireless-controller vap
  edit "Home-Corp"
    set ssid "CorpNet-Remote"
    set security wpa2-only-enterprise
    set local-bridging disable        # tunnel to HQ
  next
end

config wireless-controller vap
  edit "Home-Personal"
    set ssid "HomeNetwork"
    set security wpa2-only-personal
    set local-bridging enable         # local internet breakout
  next
end

NAT traversal

The AP connects from behind the employee’s home NAT/router. CAPWAP uses UDP, which traverses most NAT without issue. If the ISP uses CGNAT (carrier-grade NAT), a CAPWAP keepalive ensures the NAT binding stays alive.

Troubleshooting

Common issues and their diagnostic path

AP shows “Disconnected” or keeps flipping between Connected/Disconnected:

diagnose wireless-controller wlac -d wtpv2 <ap-name>

Look for CAPWAP keepalive failures. Check MTU — CAPWAP adds overhead; if the uplink MTU is 1500, CAPWAP frames may exceed it. Either reduce the CAPWAP MTU on FortiGate or increase the uplink MTU.

Clients associate but get no IP address:

diagnose wireless-controller wlac -d sta

Check the client is in the correct VLAN. If dynamic VLAN is in use, confirm the RADIUS response has the VLAN attributes. Check the DHCP server is running on the correct VLAN interface.

Poor throughput / high retries:

diagnose wireless-controller wlac -d sta | grep "retry\|signal"

High retry count = poor signal or co-channel interference. Check RSSI. Use spectrum analysis to check channel utilisation. Consider adjusting channel or reducing Tx power to reduce co-channel interference.

Clients not roaming between APs:

diagnose wireless-controller wlac -d sta

Check the client’s RSSI on both the current and target AP. FortiAP supports 802.11r (Fast BSS Transition) and 802.11k (neighbour reports) for improved roaming. Enable on the VAP:

config wireless-controller vap
  edit "Corp-WiFi"
    set fast-bss-transition enable   # 802.11r
    set bss-transition enable        # 802.11v
  next
end

AP console commands (SSH to FortiAP):

# Check CAPWAP state
cw_diag capwap_dtls
# Check radio stats
cw_diag radio-stats
# Check associated clients
cw_diag stations
# Check RF environment (channel, noise)
cw_diag rf-stats

WIDS Event Response Flow

When a WIDS event fires in FortiGate:

  1. Alert generated — visible in Log & Report > Events > Wireless or forwarded to FortiAnalyzer.
  2. Classify the AP — rogue vs neighbour. Check if the BSSID appears in the switch MAC table (on-wire = rogue).
  3. Locate physically — use the AP signal strength map in WiFi & Switch Controller > RF Analysis to triangulate.
  4. Investigate — is it an employee who plugged in a personal AP? A misconfigured guest AP? Malicious?
  5. Remediate — physically disconnect (rogue), or add to approved neighbour list (legitimate AP from an adjacent business).

Exam Scenarios

Q: WIDS is enabled but FortiGate is not detecting a known evil-twin AP in the lab. A: The monitoring radio must be in the same band and channel as the evil-twin. If the evil-twin is on 5 GHz channel 36 and the monitoring radio is scanning 2.4 GHz, it won’t detect it. Check the WIDS scan channel config and ensure the monitor radio covers the relevant bands.

Q: A mesh leaf AP connects to the root AP but clients on the leaf AP have very poor throughput. A: This is a classic mesh half-duplex problem. The leaf AP’s radio is doing backhaul to the root AP on the same band it’s using for clients. Use a tri-radio AP as the leaf so one radio handles clients and a separate radio handles the backhaul, or accept the ~50% throughput degradation.

Q: An OfficeExtender AP is deployed at an employee’s home but corporate SSID clients can’t reach internal resources. A: Check the VPN tunnel state on FortiGate. If the tunnel is up, check the firewall policy — the CAPWAP management traffic and the VPN tunnel traffic may both need policies permitting access to internal subnets. Also check that split-tunnel is configured correctly so only corporate traffic goes through the tunnel.