NSE6 Part 14: FortiNAC HA, Reporting, and End-to-End Troubleshooting

9 June 2026 NSE6Fortinet

The FCA-FNAC exam’s final topic cluster is operational: high availability, what happens when something goes wrong, and how to read FortiNAC’s own logs to find out why. The exam scenarios in this area are the most realistic — “FortiNAC is in production and a switch stopped enforcing VLANs. What do you check first?” This part gives you the systematic framework to answer that.

FortiNAC HA — Mechanics

Architecture recap

Active/passive HA with a shared Virtual IP (VIP). The primary handles all authentication, enforcement, and GUI access. The standby replicates and waits.

What replicates

DataReplication method
Configuration (policies, groups, rules)MySQL replication, near real-time
Host records (MAC, IP, device type, state)MySQL replication
Guest accountsMySQL replication
Event logsMySQL replication
Certificates / key materialFile sync
Current RADIUS sessionsPartial — in-flight sessions may need re-auth after failover

What does not survive failover: Active 802.1X sessions authenticated by the primary. After failover, endpoints may need to re-authenticate (FortiSwitch re-sends RADIUS requests to the VIP, which is now on the new primary). In most deployments this happens transparently — the re-auth completes in under a second.

Failover triggers

  • Primary heartbeat timeout (default ~30 seconds of no heartbeat before standby promotes)
  • Primary hardware failure
  • Primary network interface down
  • Manual failover (for maintenance)

Manual failover

# GUI: System > High Availability > Force Failover
# Confirm and proceed

After a manual failover:

  1. The former primary demotes to standby.
  2. The new primary (former standby) takes the VIP.
  3. Traffic flows to the new primary.
  4. The former primary restarts the FortiNAC services and begins syncing as the new standby.

Monitoring HA state

# FortiNAC CLI:
show high-availability

# Output shows:
# Role: Primary / Standby
# State: Normal / Failover
# Database sync: In Sync / Out of Sync
# Last failover: timestamp

If Database sync: Out of Sync, investigate before relying on the standby for failover. A standby with a stale database will lose host records when it promotes.

Logging and Events

FortiNAC event framework

Every action in FortiNAC generates an event:

Event categoryExamples
Host eventsNew host discovered, host state change, CoA sent, VLAN change
Auth eventsRADIUS auth success/fail, 802.1X negotiation
Compliance eventsCompliance scan started, pass, fail, quarantine triggered
Admin eventsConfig change, policy update, manual VLAN change
System eventsService started/stopped, DB sync state, HA failover
Security eventsRogue device detected, disabled device attempted connection

Event viewer

Logs > Events

Filter by: time range, event type, host MAC/IP, switch/port, severity. The event log is the first place to look when troubleshooting — search for the endpoint’s MAC and you get its full history from first discovery to current state.

Alarms

Alarms are actionable alerts triggered by specific event patterns:

Administration > Alarms

Examples:

  • New rogue device detected → email to security team
  • Compliance failure rate > 10% in 1 hour → email to admin
  • HA failover occurred → page on-call
  • Network device unreachable (SNMP poll timeout) → email to network team

Alarms can deliver via email, SNMP trap, syslog, or SMS.

Syslog

Send FortiNAC events to a SIEM or FortiAnalyzer: Administration > System > Syslog

Syslog format: CEF (Common Event Format) or RFC 5424 syslog. Most SIEM products accept either.

Fields in a FortiNAC CEF syslog event:

CEF:0|Fortinet|FortiNAC|9.4.0|802.1X-Auth-Success|802.1X Auth Success|5|
  src=192.168.100.50 smac=aa:bb:cc:dd:ee:ff dvc=10.1.1.5 
  dvchost=FortiSwitch-01 in=GigabitEthernet0/5 
  cs1=corporate-laptop cs1Label=DeviceType
  cs2=VLAN100 cs2Label=AssignedVLAN

FortiAnalyzer integration

Administration > System > FortiAnalyzer

Add the FAZ IP and register. FortiNAC sends events as syslog to FAZ in CEF format. In FAZ, FortiNAC events appear under the FortiNAC log type and can be correlated with FortiGate, FortiSwitch, and FortiAP events for full network context.

SNMP traps

FortiNAC can send SNMP traps for system health events: Administration > System > SNMP

Define trap receiver IP and community string. Useful for integrating with NMS platforms (LibreNMS, PRTG, SolarWinds).

Reporting

Built-in reports

Reporting > Reports

Pre-built report templates cover the most common operational and compliance views:

ReportWhat it shows
Host Compliance SummaryPass/fail rates per security policy
Guest ActivityGuest account creation, usage, expiry
VLAN UsageWhich VLANs hosts are assigned to, distribution
Bandwidth Usage (if accounting)Per-host and per-VLAN bandwidth
Rogue DevicesUnregistered devices by switch/port
Host Registration ActivityNew registrations over time
Policy Evaluation SummaryHow often each access policy matched

Custom reports

Reporting > Custom Reports > Add

The report builder uses a query language to filter the event log and host database. Select columns, grouping, sort order, and chart type (bar, pie, line).

Report scheduling

Reporting > Reports > [report] > Schedule

Deliver via email on a daily/weekly/monthly schedule. Useful for compliance evidence (weekly host compliance report to the security team).

Data retention

Administration > System > Database Maintenance

Set retention periods for:

  • Event logs (recommend 90 days minimum for compliance)
  • Host records (keep active; archive inactive after 30 days)
  • Guest account history

Large deployments generate significant event volume. Tune retention to avoid filling the VM disk.

Troubleshooting Framework

1. Network device discovery failures

Symptom: Switch not appearing in Network > Inventory > Network Devices.

Checks:
1. Ping the switch management IP from FortiNAC
   → Routing/firewall between FortiNAC mgmt and switch mgmt?

2. SNMP reachability:
   snmpwalk -v2c -c <community> <switch-ip> sysDescr
   → If this fails: wrong community string, SNMP not enabled,
     or ACL blocking UDP 161

3. SSH reachability (for CLI-based discovery):
   ssh admin@<switch-ip>
   → Credential issue or SSH ACL

4. Check FortiNAC discovery logs:
   Logs > Events > filter: "discovery"
   Look for "SNMP timeout" or "SSH auth failed"

2. Endpoint not appearing in host inventory

Symptom: Device is on the network but not in Network > Hosts.

Checks:
1. Is the switch port discovered? 
   Network > Inventory > Port by Device → is the port visible?

2. Does the ARP table show the IP?
   On FortiGate: get system arp | grep <mac>

3. Is DHCP snoop working?
   Add the FortiNAC management IP as a relay or mirror destination
   for DHCP traffic on the management VLAN

4. Has Nmap been run?
   Policy > Discovery Config > Schedule Nmap scan on the subnet

3. Access policy not matching — wrong VLAN assigned

Symptom: Device is in the host inventory but assigned to the wrong VLAN.

Checks:
1. Check host group membership:
   Network > Hosts > [host] > Groups
   Is it in the expected host group?

2. Check policy order:
   Policy > Network Access Policies
   Is a higher-priority policy matching first?

3. Use Policy Simulator:
   Policy > Policy Simulation > enter host MAC + port → shows which
   policy would match and what VLAN would be assigned

4. Check logical network mapping:
   Network > Logical Networks → is "Production" mapped to the correct
   VLAN ID on this specific switch?

4. CoA not firing / VLAN not changing mid-session

Symptom: Compliance fails or registration completes but the port VLAN doesn’t change.

Checks:
1. FortiGate switch-controller global:
   config switch-controller global
     get | grep allow-client-disconnect
   Must be "enable"

2. CoA shared secret:
   Compare RADIUS client definition on FortiNAC vs RADIUS server
   object on FortiGate — must match exactly (case-sensitive)

3. CoA source IP:
   The CoA packet arrives from FortiNAC Control Server IP.
   FortiGate RADIUS server object — is the CoA client IP allowed?
   config user radius > edit <FAC-object> > show | grep coa

4. FortiNAC CoA config:
   Policy > RADIUS Configurations > CoA Server
   CoA server IP = FortiGate IP, port 3799, shared secret

5. Firewall:
   UDP 3799 from FortiNAC to FortiGate must not be blocked

5. 802.1X authentication failing

Symptom: Endpoints landing in guest/auth-fail VLAN. RADIUS debug needed.

On FortiGate:
diagnose debug application radiusd 255
diagnose debug enable
# Trigger auth attempt
diagnose debug disable
diagnose debug reset

Look for:
- "Access-Reject from server" → FortiNAC is rejecting — check FAC/NAC auth debug
- "No response from server" → FortiNAC unreachable — check IP, port 1812, firewall
- "Wrong secret" → shared secret mismatch

On FortiNAC:
Logs > Events > filter: RADIUS + hostname/MAC
Look for auth success/fail and the reason code

End-to-End Trace: New Endpoint Joining the Network

Here is the complete data flow for a brand-new unregistered endpoint connecting to a FortiSwitch port under FortiNAC management:

T=0   Endpoint plugs in → FortiSwitch port link-up

T=1   FortiSwitch starts 802.1X: sends EAP-Request/Identity
      Endpoint responds: EAP-Response/Identity (username or MAC)

T=2   FortiSwitch wraps EAP in RADIUS Access-Request
      → Sends to FortiNAC Control Server (UDP 1812)

T=3   FortiNAC receives request
      → Looks up MAC in host database: not found
      → Creates host record: state = Unregistered
      → Runs policy evaluation: matches "Unregistered, Any port" → VLAN 30

T=4   FortiNAC returns Access-Accept
      Tunnel-Type=13, Tunnel-Medium-Type=6, Tunnel-Private-Group-ID="30"

T=5   FortiSwitch assigns port to VLAN 30
      Endpoint gets DHCP lease: 192.168.30.x
      Default gateway: FortiGate (VLAN 30 interface)

T=6   Endpoint opens browser → FortiGate captive policy redirects
      to FortiNAC registration portal at 192.168.30.1/register/

T=7   User authenticates (AD credentials via LDAP)
      Clicks "Register this device"
      FortiNAC updates host record: state = Registered, owner = [email protected]
      Device profiled as "Corporate-Laptop" via DHCP fingerprint
      Host group membership updated: now in "Corporate-Laptop" group

T=8   FortiNAC policy re-evaluates:
      "Registered + Corporate-Laptop, Office-Ports" → VLAN 100
      Triggers CoA-Request to FortiGate: Tunnel-Private-Group-ID="100"

T=9   FortiGate relays CoA to FortiSwitch
      FortiSwitch changes port VLAN from 30 to 100

T=10  Endpoint sends DHCP Discover on VLAN 100
      Gets lease: 192.168.100.x
      Full production access.

This sequence is the FCA-FNAC exam’s core scenario. Know every step and what can go wrong at each one.

Exam Scenarios

Q: After a FortiNAC HA failover, some hosts are back in the wrong VLAN despite previously being registered. A: The standby’s host database was out of sync before failover. The new primary doesn’t have the host records showing those endpoints as Registered. They are re-evaluated as Unregistered and placed in the registration VLAN. Fix: restore from backup or re-register affected hosts. Investigate why DB sync was failing before the failover.

Q: The FortiNAC GUI shows a switch as unreachable but it’s responding to pings from the FortiNAC management IP. A: SNMP polling is failing (not ICMP). Run snmpwalk -v2c -c <community> <switch-ip> sysDescr from the FortiNAC CLI. If it fails, verify the community string and that SNMP is enabled on the switch’s management interface (not just any interface). Also check if an ACL on the switch restricts SNMP access to specific source IPs.

Q: FortiNAC reports are not generating. The report scheduler appears to be configured correctly. A: Check the FortiNAC database maintenance settings — if the disk is full due to untruncated event logs, the report engine cannot write output. Free disk space and re-run the report manually to verify.