FCSS Enterprise Firewall 7.6 common mistakes
FCSS Enterprise Firewall 7.6 · Understand the traps and how to avoid them.
Assuming an interface-mode VDOM or a newly created VDOM inherits management access (HTTPS/SSH/ping) from the root or global settings, then being unable to reach the GUI after moving an interface into it.
Management access is configured per interface, and a new VDOM starts with no administrative access on its interfaces; candidates carry over the mental model that 'management is global'. In multi-VDOM mode the admin must also be assigned to that VDOM to see it.
What to do instead
After creating a VDOM and assigning interfaces, explicitly enable HTTPS/SSH/ping under the interface's administrative access, confirm the admin account's VDOM scope (super_admin vs. a restricted profile), and verify with 'diagnose sys vd list' and 'diagnose ip address list' before cutting over.
Building an HA cluster with mismatched heartbeat interfaces or without a dedicated heartbeat, then treating split-brain or flapping as a routing problem.
Candidates configure HA on the same physical ports used for data traffic or forget that heartbeat and session-sync interfaces must be directly connected and identically configured on both units; a broadcast/multicast mismatch also silently breaks heartbeat.
What to do instead
Use dedicated heartbeat and session-sync links between the peers, verify 'get system ha status' shows both units with the expected priority and override setting, and check 'diagnose sys ha checksum show' for configuration divergence before troubleshooting anything else.
Writing a firewall policy that permits traffic but forgetting that authentication requires a matching identity-based policy plus an enabled authentication scheme on the interface, so users are never prompted.
Candidates assume enabling an auth scheme is sufficient; in FortiOS the policy must reference user groups and the interface must have the auth method (e.g., FSSO, local, RADIUS) active, and captive-portal redirects only occur when the policy is configured to trigger authentication.
What to do instead
Confirm the policy's source includes the user group, the interface has the correct auth method enabled, and test with 'diagnose firewall auth list' and 'diagnose debug authd' to see whether the user is being matched or silently passed by an earlier policy.
Expecting an antivirus or IPS profile to inspect traffic that is actually being offloaded or is not matched by the profile's protocol/port scope, then concluding the profile is broken.
Security profiles only apply to traffic that hits the policy referencing them, and flow-based vs. proxy-based inspection differ in what they can decode; candidates also forget that SSL inspection requires a certificate profile to see encrypted payloads.
What to do instead
Attach the profile to the specific policy, verify the traffic matches that policy (check policy hit counters and 'diagnose debug flow'), enable the appropriate inspection mode, and add an SSL/SSH inspection profile when encrypted traffic must be examined.
Configuring static routes or policy routes that never take effect because the candidate ignores administrative distance, priority, or the fact that a more specific connected route wins.
FortiOS selects routes by longest prefix match first, then distance/priority; candidates add a default route expecting it to override a more specific route, or set a policy route without the correct incoming interface and source criteria.
What to do instead
Use 'get router info routing-table all' to see the actual installed routes and their distances, verify policy routes with 'diagnose firewall proute list', and confirm the incoming interface and source address in the policy route match the real traffic.
Running a packet capture or debug flow and interpreting the output as if all packets are shown, then missing that the drop happens before or after the capture point.
'diagnose sniffer packet' captures at a specific interface and filter; traffic dropped by a policy, by UTM, or by an RPF check may not appear where the candidate expects, and the default verbosity omits useful headers.
What to do instead
Combine 'diagnose sniffer packet any' with 'diagnose debug flow' (enable with 'diagnose debug enable'), read the flow trace's policy lookup and drop reason, and increase sniffer verbosity to see interface names and packet details.
Deploying a new FortiGate or VDOM with default administrative settings and leaving the implicit 'allow all' style default policy or a permissive any-any rule in place, then failing to explain why traffic passes that should be blocked.
Candidates focus on the rule they added and forget that policy order matters and that an earlier broad permit shadows later denies; they also overlook that intra-VDOM traffic between interfaces needs an explicit policy.
What to do instead
Review the policy list in order with hit counters, place specific deny rules before broad permits, and use 'diagnose debug flow' to confirm which policy ID is actually matching the flow.
Assuming HA failover preserves all sessions and state, then being surprised when sessions drop or asymmetric routing appears after a failover.
Session pickup must be enabled for stateful failover, and asymmetric routing across HA members or non-synchronized routing tables cause drops; candidates also forget that some features (e.g., certain proxy inspections) are not fully synchronized.
What to do instead
Enable session pickup in HA settings, verify both units run identical firmware and configuration checksums, ensure routing is symmetric across the cluster, and test failover with real traffic while watching 'get system ha status' and session counts.
Configuring FSSO or RADIUS authentication but not accounting for the fact that the user's identity is only known after a successful logon event, so pre-logon or non-domain traffic is treated as unauthenticated.
Candidates expect identity to be available for all traffic; FSSO relies on collector events from domain controllers, and RADIUS requires the client to actually authenticate, so machine accounts, guest devices, and pre-logon traffic fall outside the group match.
What to do instead
Add an explicit fallback (e.g., captive portal or a policy for unauthenticated users), verify collector connectivity with 'diagnose debug authd fsso list', and confirm the user group membership resolves before relying on identity-based policy.
Creating a VDOM and then troubleshooting inter-VDOM routing as if it were normal routing, forgetting that inter-VDOM links are required and that policies must exist on both sides.
In multi-VDOM mode, VDOMs are isolated routing domains; traffic between them needs an inter-VDOM link (or a shared interface) plus firewall policies in each VDOM permitting the flow in both directions.
What to do instead
Create the inter-VDOM link, assign addresses, add policies in each VDOM for the forward and return direction, and confirm with 'diagnose debug flow' that the packet traverses both VDOMs and matches the expected policy on each side.