General Exam Tips
- 1.Read every word of multi-select questions — the exam uses 'select ALL that apply' with no partial credit. Missing one option loses the entire question.
- 2.Policy order questions are the most-tested concept: always visualize the policy table top-to-bottom and ask 'which policy matches FIRST?'
- 3.For scenario questions, identify the constraint in the question (no IP change, passive auth, clientless access) before looking at the options.
- 4.When you see 'users can connect but cannot reach resources' in a VPN or auth scenario, the answer is almost always a missing firewall policy.
- 5.If the question involves CLI output interpretation, diagnose vpn ike gateway list = Phase 1, diagnose vpn tunnel list = Phase 2. Do not mix these up.
- 6.Flag and skip any question taking more than 90 seconds — come back to it. The exam is 90 minutes for 50 questions, which gives you about 100 seconds per question on average.
- 7.For 'what is wrong' troubleshooting scenarios, work through the OSI model: interface up? route? policy match? NAT? security profile? SSL inspection?
- 8.On multiple-select questions, use elimination — identify clearly wrong options first, then decide among the remaining candidates.
- 9.Do not second-guess your first instinct on straightforward definitional questions. Change answers only if you find a concrete reason to.
Quick Navigation
Deployment and System Configuration
Must-Know Facts
- NAT/Route mode = Layer 3, routing + NAT, interfaces have IPs. Transparent mode = Layer 2 bridge, no interface IPs, no NAT, no routing — used to insert inline without re-addressing.
- Transparent mode still enforces firewall policies and security profiles — it is NOT a pass-through switch. The firewall is active, just at Layer 2.
- HA Active-Passive: primary handles ALL traffic. Secondary monitors via heartbeat. On failover, secondary promotes to primary. The demoted unit rejoins as secondary when it recovers.
- HA Active-Active: primary distributes sessions to ALL units. All units process traffic. Primary holds the cluster virtual MACs and receives all inbound; response packets from subordinate units go directly out without returning through primary.
- HA session pickup is NOT enabled by default. Without it, active sessions drop on failover. Proxy-based sessions (SSL VPN, explicit proxy) cannot be handed off regardless — they must restart.
- Trusted hosts restrict login SOURCE IPs. If configured and your source IP is not in the list, login is blocked even with correct credentials. Always include your own management subnet.
- Factory reset restores management IP to 192.168.1.99, admin password blank.
- Log levels in order: emergency, alert, critical, error, warning, notification, information, debug. More log data = more storage overhead. Set minimum level appropriate for the deployment.
- VDOM sub-interfaces inherit the parent physical interface's zone unless explicitly reassigned — this affects which policies govern their traffic.
- FortiGate-VM does not have hardware ASIC (NP6/NP7) offloading available. All inspection is software-only, which affects throughput compared to physical appliances.
Common Traps
Confusing Pairs
Scenario Tips
A FortiGate must be inserted between an existing router and switch without changing any IP addresses or routes on existing devices.
Choose Transparent mode. The FortiGate bridges at Layer 2, requiring no interface IPs and no changes to existing device routing.
VDOM mode is wrong — VDOMs segment one FortiGate into multiple logical firewalls but do not change the deployment mode.
An HA cluster fails over but users report their browsing sessions dropped. Sessions do NOT resume automatically. Why?
Session pickup (session synchronization) was not enabled, OR the sessions are proxy-based (SSL VPN / explicit proxy) which cannot be handed off. Enable session-pickup in HA settings for stateful failover of regular sessions.
Do not assume HA automatically preserves all sessions. Proxy sessions always restart on failover regardless of session-pickup configuration.
Last-Minute Facts
Firewall Policies and Authentication
Must-Know Facts
- Policy matching is strictly top-to-bottom, first match wins. No best-match logic. A broad ALLOW above a specific DENY means the deny is never evaluated.
- The implicit deny-all (policy ID 0) is always at the bottom. Traffic not matched by any explicit policy is silently dropped.
- ALL five fields must match for a policy to fire: source interface, destination interface, source address, destination address, and service.
- SNAT IP pool types: Overload (many-to-one PAT, most common), One-to-one (dedicated external IP per internal IP, preserves ports), Fixed Port Range (static port range per source IP), Port Block Allocation (dynamic port block per source IP).
- DNAT is implemented via Virtual IPs (VIPs). A VIP maps an external IP/port to an internal IP/port. VIPs MUST be referenced as the destination address in a firewall policy to take effect.
- Central NAT and per-policy NAT are mutually exclusive per VDOM. Central NAT has a separate SNAT table and DNAT table; per-policy NAT has the NAT checkbox in each policy.
- FSSO is passive — FortiGate learns user identity from AD login events without prompting users. It does NOT show users a FortiGate login page.
- Firewall active authentication shows users a portal/captive page. FSSO is passive authentication. LDAP and RADIUS can be used for either active auth or FSSO backend.
- VIP default behavior: the 'all' address object in a policy does NOT match VIPs by default unless match-vip is enabled. To deny traffic to a VIP specifically, reference the VIP object in the destination field of the deny policy.
- FSSO workstation verification: FortiGate pings the endpoint to confirm the user is still logged in. If ICMP is blocked, workstation verification fails silently and user-based policies stop matching. Disable workstation verification if endpoints block ICMP.
Common Traps
Confusing Pairs
Scenario Tips
An internal web server at 192.168.1.10 needs to be accessible from the internet on the FortiGate's external IP 203.0.113.10:80. Users are still blocked after configuring the VIP.
The VIP was created but not added to a firewall policy. Create a policy with source interface = WAN, destination interface = LAN, destination address = the VIP object, service = HTTP, action = accept.
Do not use an IP pool here — IP pools are for outbound SNAT. VIPs handle inbound DNAT. Also do not create a static route to the internal server — routing and NAT are different things.
A company uses Active Directory. They want FortiGate to apply different policies to HR vs IT users without any additional login prompts.
Use FSSO (Fortinet Single Sign-On). FortiGate passively monitors AD login events to build IP-to-user mappings. No FortiGate login prompt is shown to users.
LDAP and RADIUS require active authentication — users see a portal or are prompted. Local user database requires maintaining separate FortiGate accounts. Only FSSO is transparent.
Traffic from 10.0.0.100 is hitting the broad allow policy instead of the specific deny policy below it.
Move the specific deny policy ABOVE the broad allow policy. Policy tables are top-to-bottom first-match — specific exceptions must appear before the broad rule they override.
You cannot fix this with administrative distance or priority — those are routing concepts. Policy order is the only solution.
FSSO appears to be working (Collector Agent shows logins) but user-based policies are not matching for some users.
Check whether FSSO workstation verification is enabled. If endpoints block ICMP pings from FortiGate, verification fails silently and user-to-IP mappings are not used. Disable workstation verification or allow ICMP from FortiGate to endpoints.
Do not immediately blame the Collector Agent configuration — the agent is logging logins correctly. The failure is in FortiGate's confirmation step (ICMP workstation check).
Last-Minute Facts
Content Inspection
Must-Know Facts
- Security profiles (AV, IPS, web filter, app control, DNS filter, DLP) do NOTHING unless attached to a firewall policy. Creating the profile is not enough.
- Without an SSL inspection profile on a policy, ALL encrypted HTTPS/SMTPS/IMAPS traffic is invisible to AV, IPS, and web filter. Malware in HTTPS tunnels is undetectable.
- Certificate inspection validates the TLS certificate only — it does NOT decrypt traffic. No content inspection is possible. No CA cert required on endpoints.
- Deep/Full SSL inspection decrypts, inspects, re-encrypts. Requires the FortiGate SSL inspection CA certificate to be trusted by all endpoints. Without this, browsers show 'untrusted certificate' warnings.
- Deep SSL inspection breaks certificate-pinned apps (banking, some Office 365 features). Use SSL exemptions for these domains.
- Proxy mode buffers full content before inspection — more thorough, higher latency/memory. Flow mode inspects streaming packets — lower latency, uses different detection engine.
- In FortiOS 7.6, DLP supports BOTH flow and proxy feature-sets. Proxy mode DLP = full file buffering for deeper analysis. Flow mode DLP = stream-based scanning. Both work but proxy is more thorough.
- Web filter uses FortiGuard cloud category lookups for URLs. Requires internet connectivity to FortiGuard servers and active web filtering subscription.
- Application control identifies apps by Layer 7 DPI signatures regardless of port or protocol. It can block BitTorrent on any port, WhatsApp on non-standard ports, etc. Web filter cannot do this.
- When FortiGuard subscription expires, signatures stop updating but the feature continues working with stale last-known signatures/categories.
- Application control has its own logging toggle. IPS logging being enabled does NOT automatically enable application control logging. Only blocked applications log without enabling 'log all sessions'.
- Botnet C&C blocking requires active FortiGuard subscription and is enabled within AV or IPS profiles — not a standalone feature.
Common Traps
Confusing Pairs
Scenario Tips
IPS and AV profiles are attached to a policy. An attacker sends malware inside an HTTPS connection. Will the profiles detect it?
No. Without an SSL inspection profile applied to the same policy, HTTPS content is encrypted and invisible. Add a deep SSL inspection profile to the policy to enable content scanning of HTTPS.
IPS does NOT operate below the encryption layer — it cannot decrypt TLS on its own. Both IPS and AV require the FortiGate to have decrypted the traffic first via SSL inspection.
After enabling deep SSL inspection, users report 'untrusted certificate' errors on every HTTPS website. The FortiGate is correctly intercepting traffic. What is the fix?
Deploy the FortiGate's SSL inspection CA certificate to all endpoint operating systems or browsers (via Group Policy, MDM, or manual installation). This makes clients trust the FortiGate-signed certificates.
Adding certificate exemptions for every site is impractical and does not solve the root cause. Switching to certificate inspection avoids the error but also loses content inspection capability.
Web filter is configured and active, but users are still using BitTorrent to download files.
Add an application control profile with BitTorrent blocked in the P2P category. BitTorrent operates on arbitrary ports and does not use URLs — web filter cannot block it. Application control DPI signatures identify it regardless of port.
IPS profile is for blocking attacks/exploits, not blocking application usage. DNS filter blocks domain resolution but BitTorrent uses IP tracker connections that bypass DNS.
Last-Minute Facts
Routing
Must-Know Facts
- Administrative distance determines preference between routes from DIFFERENT sources. Lower = preferred. Static = 10, eBGP = 20, OSPF = 110, iBGP = 200.
- Priority is the tie-breaker for routes with the SAME administrative distance (e.g., two static routes). Lower priority value = more preferred. Priority 0 wins over priority 5.
- ECMP requires equal distance AND equal priority. If either differs, no ECMP — the lower value wins exclusively.
- Policy routes (PBR) are evaluated BEFORE the routing table. They override any routing table entry, regardless of how specific it is.
- SD-WAN rules are evaluated top-to-bottom like firewall policies. First matching rule wins. Place application-specific rules ABOVE broader address-based rules.
- SD-WAN performance SLA health checks monitor link quality (latency, jitter, packet loss) but do NOT steer traffic by themselves. SD-WAN rules that REFERENCE the SLA determine traffic placement.
- SD-WAN load balancing algorithms: source-ip-based (default, hash on src IP), weight-based, usage-based/spillover (use primary until threshold), source-dest-ip-based, measured-volume-based.
- Route monitoring (link health monitor): if a monitored IP becomes unreachable, static routes with that monitor are removed from the routing table — enabling failover to backup routes.
- eBGP neighbors: different AS numbers. iBGP neighbors: same AS. FortiGate supports both for dynamic routing with ISPs (eBGP) and internal networks (iBGP or OSPF).
Common Traps
Confusing Pairs
Scenario Tips
Two default routes exist: ISP1 with distance 10, priority 0 and ISP2 with distance 10, priority 10. Both links are up. Which is used?
ISP1. Same distance, so priority is the tie-breaker. Priority 0 is preferred over priority 10 (lower value wins). This is NOT ECMP because the priorities differ.
Do not confuse higher priority VALUE with higher preference. In FortiOS, LOWER priority number = MORE preferred, not the other way around.
All HR traffic from 10.1.1.0/24 must exit WAN2, while all other traffic uses the standard routing table.
Create a policy route matching source address 10.1.1.0/24 with WAN2 as the outgoing interface. Policy routes override the routing table for matching traffic.
A static route matches destination, not source — you cannot differentiate traffic by source subnet using a static route. SD-WAN rules work only if WAN interfaces are SD-WAN members.
Last-Minute Facts
VPN
Must-Know Facts
- IKE Phase 1 establishes the ISAKMP SA (secure management channel). Parameters: authentication method (PSK or cert), encryption, hash/integrity, DH group, lifetime. ALL must match on both peers.
- IKE Phase 2 establishes the IPsec SA (data encryption). Parameters: encryption, hash/integrity, PFS DH group, proxy IDs (for policy-based), lifetime. ALL must match on both peers.
- Phase 1 failure = no tunnel at all. Phase 2 failure = Phase 1 is up but no traffic flows. Understanding which phase failed is critical for troubleshooting.
- Route-based VPN creates a virtual tunnel interface (VTI). Traffic is routed into the tunnel via static or dynamic routes. Policies reference the tunnel as source/destination interface.
- Policy-based VPN has no tunnel interface. Traffic is selected by proxy IDs (local subnet, remote subnet). Required for interoperability with devices that enforce specific proxy IDs.
- Route-based VPN is the Fortinet-recommended approach. It supports dynamic routing (OSPF/BGP over tunnel), ECMP, and easier HA failover.
- SSL VPN tunnel mode requires FortiClient and creates a virtual NIC. Users get an IP from the SSL VPN IP pool and are routed into the internal network via the ssl.root virtual interface.
- SSL VPN web mode is clientless (browser only). FortiGate acts as a reverse proxy. Access is limited to HTTP/HTTPS applications via bookmarks.
- SSL VPN requires TWO mandatory components: (1) portal/user group configuration and (2) a firewall policy from ssl.root to the internal destination interface. Both must exist for users to access resources.
- Split tunneling in SSL VPN sends only specified subnets through the VPN tunnel. All other traffic (internet browsing) goes directly out the user's local connection. Without split tunneling, ALL traffic goes through corporate VPN.
Common Traps
Confusing Pairs
Scenario Tips
A site-to-site IPsec VPN Phase 1 fails even though pre-shared keys match on both ends.
Check Phase 1 proposal parameters: encryption algorithm, hash/integrity algorithm, and Diffie-Hellman group must all match on both peers. A single mismatched parameter prevents Phase 1 from establishing.
Proxy IDs (local/remote subnets) are Phase 2 parameters — they do not affect Phase 1 negotiation. Tunnel interface IPs are route-based VPN config, not Phase 1 negotiation parameters.
An SSL VPN user connects and receives an IP from the VPN pool but cannot reach any internal hosts. They can ping the FortiGate's internal interface IP.
A firewall policy from ssl.root to the internal network interface is missing or not matching the traffic. Create a policy: srcintf=ssl.root, dstintf=internal, source=all (or VPN pool), destination=internal subnet, action=accept.
The fact that the user can ping the FortiGate itself does not mean internal host access is working — the FortiGate responds to ping on its own interface from ssl.root, but traffic to LAN hosts requires a separate policy.
Which CLI command shows the status of active IKE Phase 1 security associations including peer IP and authentication status?
'diagnose vpn ike gateway list' shows Phase 1 ISAKMP SA status. 'diagnose vpn tunnel list' shows Phase 2 IPsec SA status. 'get vpn ssl monitor' shows SSL VPN user sessions.
'diagnose debug application ike -1' enables REAL-TIME IKE debug output, not a status summary — do not confuse it with a status command.