FCP FortiGate Administrator common mistakes
FCP FortiGate Administrator · Understand the traps and how to avoid them.
Reading a firewall policy top-down and assuming the first policy whose source, destination, and service match will handle the traffic, without checking whether a more specific policy above it or an implicit deny below it changes the outcome.
Candidates memorize policy fields but forget that FortiGate evaluates policies sequentially and stops at the first full match, so they predict the wrong policy (and wrong NAT/logging behavior) for a given flow.
What to do instead
For every policy-evaluation question, walk the policy list from the top, confirm source interface, source address, destination address, service, and schedule all match, and identify the first complete match; remember unmatched traffic hits the implicit deny.
Treating NAT as a single on/off setting instead of distinguishing source NAT (outbound interface or pool) from destination NAT (VIP, IP pool with port forwarding, central NAT), and mispredicting which address the server sees.
The GUI presents NAT as a checkbox plus optional pool, so candidates overlook that destination NAT via VIP also requires a policy and that the original source may be preserved or translated depending on pool type.
What to do instead
For each NAT scenario, state explicitly: direction of translation, object used (VIP vs IP pool), whether the policy has NAT enabled, and whether preserve-source-IP or a fixed-port pool is in play; verify with the session table concept (original vs reply tuple).
Assuming a static route alone determines forwarding, ignoring policy routes, SD-WAN rules, and the fact that a route is only installed if its outgoing interface is up and its gateway is reachable.
Candidates study route tables in isolation and forget FortiGate's order of operations, including policy route precedence over the routing table and administrative distance/priority tie-breaking.
What to do instead
When troubleshooting reachability, check in order: policy routes, SD-WAN rules, then the routing table (longest prefix match, then distance, then priority); confirm the egress interface is up and the next hop resolves via ARP.
Configuring an interface in the wrong mode (switch vs interface, or forgetting to assign the correct role/zone) and then expecting DHCP, routing, or policy references to work.
Lab habits lead candidates to treat every port as a routed interface, but FortiGate uses hardware switch/software switch, zones, and VLAN sub-interfaces whose behavior differs for policy and routing.
What to do instead
Before answering, identify the interface type, whether it is in a zone, its IP/ DHCP role, and whether VLAN tagging is needed; confirm policy references use the zone or interface name actually configured.
Mixing up authentication methods (local password, LDAP/AD, RADIUS, SAML/SSO, certificate) and forgetting that firewall policies can require user groups, so identity must be resolved before policy match.
Candidates learn each method separately but not how FortiGate maps a user to a group and applies that identity in policy evaluation, especially with FSSO vs polling vs agentless.
What to do instead
For any auth question, trace: authentication source, user/group object, which policy references the group, and whether the traffic is pre- or post-authentication; remember user-based policies are matched after identity is known.
Configuring a security profile but not applying it to the correct policy, or applying it to a policy that never matches the traffic being tested, then concluding the profile is broken.
Profiles are policy-scoped, and candidates often forget profile mode (proxy vs flow) changes which features are available and how inspection behaves.
What to do instead
Confirm the profile is attached to the policy that actually matches the flow, check the inspection mode (flow vs proxy) supports the feature, and verify logging is enabled on that policy to see profile actions.
Assuming antivirus, IPS, web filter, and SSL inspection all inspect the same traffic, and expecting encrypted traffic to be scanned without configuring certificate inspection or deep inspection.
Candidates treat security profiles as a bundle, but each has its own protocol coverage, and without SSL inspection most content in HTTPS is invisible to the profile.
What to do instead
Map each profile to the protocols it inspects, and for HTTPS explicitly choose certificate inspection (SNI/category only) vs deep inspection (full content) with the correct CA certificate pushed to clients.
Building an IPsec tunnel but mismatching phase 1/phase 2 parameters (proposal, DH group, PSK, remote gateway, selectors) and then debugging only one side.
Candidates configure one peer from memory and assume defaults match, but IKE proposals, PFS, and traffic selectors must agree on both ends, and dial-up vs static topology changes requirements.
What to do instead
Compare phase 1 (version, encryption/auth, DH, PSK/cert, remote gateway, NAT traversal) and phase 2 (proposal, PFS, local/remote subnets) on both peers; use IKE debug and tunnel status to see which phase fails.
Enabling logging on some policies but not others, then troubleshooting with incomplete logs, or confusing traffic logs, event logs, and security logs when reading the log viewer.
Candidates assume logging is global, but it is per-policy and per-profile, and each log type records different events, so missing entries are often a logging-configuration gap rather than a traffic problem.
What to do instead
Enable logging (and log-all-sessions when needed) on the relevant policies and profiles, then read the correct log type: traffic for sessions, security for profile hits, event for admin/system/auth events.
Relying on default admin access and not accounting for admin profiles, trusted hosts, and VDOM scope when describing who can manage the device or see which objects.
Candidates focus on traffic features and overlook administrative access controls, so they misjudge why an admin cannot log in or cannot see a policy in a multi-VDOM setup.
What to do instead
For management questions, check admin profile permissions, trusted host restrictions, the interface's administrative access protocols, and the current VDOM context (global vs per-VDOM objects).