The up-to-two-minute delay occurs because the wireless controller must onboard a client onto a temporary, isolated VLAN to collect. Its telemetry data (like MAC address, OS, or EMS tags) before it can evaluate NAC policies. Once the information is captured, the controller disconnects the client and forces a reconnect to assign the final, authorized VLAN.
When deploying Network Access Control (NAC) on Fortinet wireless infrastructure, administrators often notice a delay of up to two minutes before a client is assigned its correct, policy-based Virtual Local Area Network (VLAN). While this behavior might initially look like a performance issue or a network lag, it is actually a foundational component of the automated onboarding design.
The sequential mechanism below explains why the delay takes up to 120 seconds: [Client Connects] -> [Assigned Onboarding VLAN] -> [Telemetry & EMS Sync (Up to 2 Min)]. [Final VLAN Assigned] <- [Client Reconnects] <- [Forced Disconnect] <- [Policy Match].
The up-to-two-minute window accounts for the time required to reliably process network traffic, complete background API syncs with the EMS database, and complete the device classification cycle. This behavior is explained under the Example section: Configuring wireless NAC support
Additionally, the WiFi NAC check interval can be adjusted to reduce the waiting time before the wireless controller re-evaluates the connected wireless clients. The nac-interval setting defines the interval, in seconds, between two WiFi Network Access Control checks performed by the wireless controller. The default value is 120 seconds, and the supported range is 10 to 600 seconds. To reduce the interval to the minimum supported value, use the following command:
config wireless-controller global
set nac-interval 10
end
With the default value of 120 seconds, the wireless controller performs WiFi NAC checks every 2 minutes. Reducing this value may help the wireless controller apply NAC matching changes faster for wireless clients connected to SSIDs where NAC is enabled.
This setting does not control 802.1X authentication, EAP reauthentication, DHCP, roaming, or wireless client session timeout. It only controls the interval between WiFi NAC checks performed by the wireless controller.
In case the connection takes more than 2 minutes, gather the log information required:
FortiGate window 1 using Putty session:
diagnose firewall dynamic list
diagnose firewall dynamic address
If the tag lookup with this command takes seconds before the VAP output shows the new VLAN, the bottleneck is EMS/tag sync.
If the tag appears instantly but the VAP still shows the old VLAN for a long time, focus on the wireless controller (cw_acd, AP tunnel, or VAP refresh).
diagnose firewall dynamic address EMS<EMS_ID>ZTNA<tag‑name>
diagnose test application fcnacd 5
It forces a host‑tags API call; note any latency or error messages.
diagnose debug enable
get wireless-controller status
diagnose wireless-controller wlac -c ws
diagnose wireless-controller wlac -c vap
diagnose wireless-controller wlac -c stats
diagnose wireless-controller wlac_hlp -c sta-nac
diagnose switch-controller mac-device nac known
diagnose switch-controller mac-device dynamic
diagnose switch-controller mac-cache show
diagnose user-device-store device memory list
diagnose user device list
diagnose endpoint fctems test-connectivity <connector ID>
It should report success.
diagnose debug application fcnacd -1
Watch for 'http code 500' or other failures.
| 
