All certifications / FortiGate Admin / Cheat sheet

FortiGate Admin NSE4_FGT_AD-7.6 cheat sheet

Every exam tip and key term from the free FortiGate Admin lessons, by domain. Use your browser's Print to save it as a PDF.

Domain 1: Deployment and system configuration (24%)

Exam tips

Losing GUI access after an interface change is almost always a missing HTTPS entry in that interface's Administrative Access. Confirm allowaccess before you disconnect.
When a question asks how to restrict where an admin logs in from, the answer is trusted hosts, not MFA or password policy. Profiles answer what they can change, not where.
Never flash the newest image straight over a much older build. Follow the published upgrade path step by step, and take an encrypted backup first so you can roll back.
VDOMs give separate routing tables and policy sets; VLANs and zones only segment within one routing/policy context. Choose VDOMs when you need real isolation, not just subnets.
Memorize both election orders. Override disabled: interfaces, uptime, priority, serial. Override enabled: interfaces, priority, uptime, serial. Priority only matters early when override is on.
Session pickup is disabled by default. If a question mentions sessions dropping across a failover, the fix is to enable session pickup, not to add heartbeat links or override.
Two Fabric facts recur on the exam: the root must have FortiAnalyzer or cloud logging, and downstream units are authorized by serial number on the root. A shared account or VPN does not make a Fabric.
When the question asks for the simplest way to react instantly to an event, pick an automation stitch. Scheduled reports and syslog forwarding are not immediate and need extra tooling.
Memory logs are wiped on reboot. For any question about keeping log history, the answer is a persistent destination: disk, FortiAnalyzer, FortiGate Cloud or syslog, not a bigger memory buffer.
Adding vCPUs beyond what the VM license permits does not increase throughput. In cloud, remember traffic reaches the FortiGate through cloud route tables, and HA uses SDN mechanisms, not shared MACs.
av-failopen governs proxy antivirus in conserve mode; IPS fail-open governs the IPS engine. Do not confuse them. And a flow trace prints nothing until you run diagnose debug enable.

Key terms

Management IP (192.168.1.99): The default address on a factory FortiGate's management/internal interface, reached over HTTPS for first login.
Administrative access: The per-interface list of management services (HTTPS, SSH, PING, SNMP, and so on) that the FortiGate will answer on that interface.
Interface role: A label (LAN, WAN, DMZ or Undefined) that tailors which configuration fields are shown for an interface; it does not filter traffic on its own.
allowaccess: The CLI keyword under a system interface that sets which management protocols the interface accepts.
Admin profile (access profile): Per-feature read/read-write/none permissions that define what an administrator can do; super_admin is the full built-in profile.
Trusted hosts: A per-account list of allowed source subnets; once set, logins from any other address are refused.
MFA / two-factor for admins: A second login factor (such as a FortiToken code) that protects against stolen passwords but does not limit source networks.
Password policy: Rules for admin password length, complexity and expiry.
Upgrade path: The ordered sequence of intermediate FortiOS builds Fortinet requires between two versions so the configuration converts correctly.
Configuration backup: A saved copy of the whole FortiGate configuration, optionally encrypted with a password, used for rollback or cloning.
Restore: Loading a saved configuration file, which replaces the running config and reboots the unit.
Release notes: Fortinet's per-build document listing the supported upgrade path, fixes and known issues.
VDOM (virtual domain): An isolated instance on one FortiGate with its own interfaces, routing table, policies and profiles.
Root VDOM: The default VDOM that always exists and, in multi-VDOM mode, hosts management and box-wide functions.
Global vs per-VDOM settings: Global settings (firmware, HA, hostname) apply to the whole unit; per-VDOM settings (interfaces, routes, policies) belong to one VDOM.
Inter-VDOM link: A virtual internal link that connects two VDOMs so traffic can pass between them under policy control.
FGCP: FortiGate Clustering Protocol, which binds matching FortiGates into one HA cluster with shared virtual addresses.
Active-passive vs active-active: Active-passive: only the primary forwards traffic. Active-active: the primary also distributes inspection sessions to secondaries.
Heartbeat link: A dedicated interface carrying HA health, config sync and session sync; two are used to avoid split brain.
Override: An HA setting that moves device priority ahead of uptime in the election, so a preferred unit reclaims the primary role after recovery.
Session pickup: HA session synchronization that lets established TCP sessions survive a failover; off by default because of its CPU and heartbeat cost.
Configuration sync: The automatic replication of the primary's configuration to secondaries so all members stay identical.
HA checksum: A per-configuration-area hash compared across members to confirm they are in sync; a mismatch reveals which area differs.
execute ha manage: A CLI command that connects you from one cluster member to another member's console over the heartbeat link.
Fabric root: The top FortiGate in a Security Fabric that aggregates the topology and requires FortiAnalyzer or cloud logging.
Downstream FortiGate: A FortiGate that joins the Fabric by connecting to the upstream (root) IP and being authorized by the root.
Fabric authorization: The root's approval of a downstream unit by serial number, which completes the join and blocks unknown devices.
Security Rating: A Fabric feature that checks devices against Fortinet best practices and returns a score with prioritized fixes.
Automation stitch: A rule that pairs a trigger with one or more actions so the FortiGate responds to an event automatically.
Trigger: The event that starts a stitch, such as a configuration change, a security detection, a schedule or an incoming webhook.
Action: What a stitch does when triggered: email, outbound webhook, CLI script, or quarantine, among others.
Quarantine action: An action that isolates a compromised host (for example by banning its address) to contain a threat automatically.
Traffic log: A record of sessions passing through firewall policies, including the policy hit and allow/deny result.
Event log: A record of the FortiGate's own activity: admin logins and changes, HA, VPN and system health.
Security (UTM) log: A record of security-profile actions such as antivirus, web filter, IPS, application control and DNS filter events.
Log allowed traffic: A per-policy setting (No Log, Security Events, All Sessions) that controls which accepted sessions are logged.
FortiGate-VM: FortiOS running as a virtual machine on a hypervisor or public cloud, licensed in software.
VM licensing (vCPU-bound): A license tied to a virtual model that caps usable vCPUs; extra vCPUs beyond the license do not add capacity.
BYOL vs PAYG: Cloud licensing models: Bring Your Own License uses a license you purchased; pay-as-you-go bills the license hourly through the cloud provider.
SDN connector: A FortiOS integration that lets policies reference dynamic cloud objects (tags, security groups) so rules follow scaling workloads.
get system performance status: A CLI summary of live CPU, memory, session and throughput load plus uptime.
Conserve mode: A protective state entered when free memory crosses a threshold, stopping new proxy-based inspection until memory recovers.
av-failopen: The global setting deciding whether traffic needing proxy antivirus passes uninspected (pass), is dropped (off), or bypasses AV until an admin resets it (one-shot) during conserve mode.
diagnose debug flow: A trace of how the FortiGate handles a packet, showing route lookup, policy match, NAT and any deny reason.

Domain 2: Firewall policies and authentication (22%)

Exam tips

Policy ID is only a label. When a specific rule is not taking effect, look at its position in the list, not its number, and check whether a broader rule above it matches first.
For a big, changing cloud service, choose the ISDB entry. A single FQDN misses many endpoints and a geography object is far too broad to identify one service.
Policy ID is fixed and does not set order; sequence (list position) does. Reordering changes sequence, not IDs, so never reason about matching from the ID number.
One-to-one caps concurrent users at the number of pool addresses because it does not use port translation. For many users on few IPs, always choose overload.
Central SNAT and per-policy NAT are mutually exclusive. After enabling central SNAT, policies no longer translate on their own; you must recreate translations as table entries or traffic leaves untranslated.
The inbound policy's destination is the VIP itself, not the internal IP. And only a port-forwarding VIP rewrites the port; a service object merely matches traffic and never translates ports.
Policies reference user groups, not LDAP/RADIUS server entries directly. For Active Directory group lookups, choose regular bind, since anonymous and simple bind cannot search group memberships.
Captive portals only trigger on HTTP/HTTPS (and FTP/Telnet), and DNS cannot trigger them. Always allow DNS in a policy above the authentication policy or login is impossible.
If a new AD group's members never match policies, check the FSSO group filter first, that group is probably not selected, so its membership is never sent to the FortiGate.
FortiToken is assigned per user account, not via an admin profile toggle or a password rule. Enabling two-factor on the account and binding the token is the configured answer.

Key terms

Matching criteria: The fields FortiGate compares to place a session: incoming/outgoing interface, source, destination, service and schedule.
Top-down first match: Policies are evaluated in list order and the first one that matches is used; order, not policy ID, decides.
Implicit deny (policy 0): The final rule that drops any traffic no policy matched, making the FortiGate deny-by-default; it does not log by default.
Security profile timing: Profiles are applied after a policy matches, so they never influence which policy is selected.
Address object / group: A named IP host, subnet or range (object) or a bundle of them (group) reused across policies.
FQDN object: An address object based on a domain name that the FortiGate resolves via DNS and keeps current.
Geography object: An address object covering all IP ranges of a country, based on FortiGuard geolocation data.
Internet Service Database (ISDB): A FortiGuard-maintained catalog of public services with their current addresses, protocols and ports, usable as a policy source or destination.
Policy lookup tool: A GUI tool that takes hypothetical session parameters and reports which policy they would match, using real list order.
Policy ID: A stable label assigned at creation that does not change when the policy is moved; it identifies a policy in logs and CLI but does not set matching order.
Sequence: A policy's position in the list, which is what actually determines top-down matching order.
Recurring vs one-time schedule: Recurring schedules repeat on chosen days and times; one-time schedules are active once over a single window then expire.
Source NAT (SNAT) / PAT: Rewriting the source address of outbound traffic; port address translation lets many hosts share one public IP by unique source ports.
Overload IP pool: A pool where many internal hosts share the pool's public addresses using port translation.
One-to-one IP pool: A pool mapping each host to its own public address with no port translation, capping concurrent users at the pool size.
Fixed port range / port block allocation: Pool types that map internal hosts to external IPs and predictable port ranges/blocks for auditable logging.
Central SNAT: A mode where all source-NAT rules live in one ordered table instead of on individual firewall policies.
Per-policy NAT: The default mode where each firewall policy carries its own NAT toggle and translation choice.
Central SNAT table order: The top-down evaluation of central SNAT entries, where the first matching entry decides the translation.
DNAT independence: Destination NAT continues to use VIPs regardless of whether central SNAT is enabled.
Virtual IP (VIP): A FortiGate object that performs destination NAT by mapping an external IP/port to an internal one.
Static NAT VIP: A VIP that maps the entire external address to the internal address for all ports (one-to-one).
Port forwarding VIP: A VIP that maps a specific external port to a specific internal port, rewriting both address and port.
VIP group: A bundle of VIPs referenced together as the destination of a single inbound policy.
Local user: An account defined directly on the FortiGate with its own username and password; simple but does not scale.
LDAP regular bind: Using a service-account DN and password so the FortiGate can search the directory and read group memberships (required by AD).
RADIUS / TACACS+: External AAA server protocols FortiGate can use to authenticate users and admins; TACACS+ is common for device administration.
User group: A FortiGate object combining local users and/or a remote server group match, referenced as a policy's source to require authentication.
Active authentication (captive portal): Explicitly prompting the user for credentials via a login page before allowing their traffic.
Passive authentication: Identifying users without a prompt by learning logons from another source, typically FSSO.
Idle vs hard timeout: Idle timeout logs a user out after inactivity; hard timeout logs them out a fixed time after login regardless of activity.
DNS-before-login rule: A policy allowing DNS without authentication, placed above the captive-portal policy, so browsers can resolve names and reach the login page.
Collector agent: A Windows service that gathers logon data and sends user-to-IP-to-group mappings to the FortiGate.
DC agent mode: An agent on each domain controller that pushes logon events to the collector in real time.
Polling mode: The collector or FortiGate periodically reads DC security event logs remotely, with no software on the DCs but more delay.
Group filter: The selection of AD groups FSSO reports to the FortiGate; groups not selected are never sent.
FortiToken: Fortinet's one-time-password token, available as a hardware keyfob or the FortiToken Mobile app, providing a TOTP second factor.
Two-factor authentication (2FA): Requiring a password plus a second proof (a token code) so a stolen password alone cannot log in.
Per-user assignment: Enabling two-factor on an individual account and binding a specific token to it, rather than a global toggle.
TOTP: A time-based one-time password that changes on a short interval, the code a FortiToken displays.

Domain 3: Content inspection (26%)

Exam tips

Only deep inspection can scan payloads (AV, full URLs, in-app actions). Certificate inspection sees only SNI/certificate. And clients must trust the FortiGate CA, or every site throws a warning.
Two separate choices: flow vs proxy (engine) and profile-based vs policy-based (rule style). In profile-based mode the inspection mode is chosen per policy, not globally or per interface.
Exempt short-circuits all remaining checks; Allow only passes the URL-filter stage and can still be blocked by the FortiGuard category. Use Exempt to guarantee a page loads.
DNS filtering's exam-key advantage is that it blocks bad domains at lookup time for any protocol without decryption. It does not scan files, so pair it with web filtering and antivirus for depth.
Application control identifies apps by signature, so use categories/overrides, not port or web-category rules, to stop things like BitTorrent. Controlling actions inside an encrypted app requires deep inspection.
CDR and reliable full-file blocking need proxy mode; flow mode is faster but more limited. Signatures catch known malware, and a sandbox is what adds behaviour analysis for unknown files.
Tune IPS with signature filters (target, OS, severity) rather than enabling everything, and use IP exemptions for false positives. Do not confuse IPS fail-open with av-failopen.
DoS policies act before firewall policy lookup, which is why they, not application control or IP pools, are the answer to stopping a SYN flood early. Baseline traffic before setting thresholds.
When signatures seem out of date or ratings fail, run diagnose autoupdate versions to check database currency and FortiGuard reachability. On the free trial VM, no FortiGuard updates is expected.

Key terms

Certificate inspection: SSL inspection that reads only the handshake (SNI and certificate) without decrypting, enabling category and app identification but not payload scanning.
Deep inspection: Full SSL inspection that decrypts, inspects and re-encrypts traffic using the FortiGate CA, required for AV and detailed inspection.
CA trust distribution: Pushing the FortiGate's signing CA to clients (via GPO/MDM) so re-signed certificates are trusted and warnings stop.
Certificate pinning: An app accepting only its own expected certificate, which rejects the FortiGate's re-signed one, requiring an inspection exemption.
Flow-based inspection: Scanning traffic as packets pass with minimal buffering; lower latency and higher throughput but fewer full-object features.
Proxy-based inspection: Buffering the whole object before scanning; supports CDR and replacement messages at higher memory and latency cost.
Profile-based NGFW mode: The default style where security profiles are attached to firewall policies, and inspection mode is set per policy.
Policy-based NGFW mode: A style where applications and URL categories are referenced directly in security policies, with SSL inspection and NAT in separate policies.
FortiGuard category action: The per-category behaviour in a web filter profile: Allow, Monitor, Warning, Authenticate or Block.
Warning action: Shows an interstitial page that lets the user choose to continue, unlike Block which gives no option.
Static URL filter (Exempt vs Allow): A URL list checked before categories; Exempt skips all remaining checks, while Allow still passes the URL to the category check.
Rating error handling: The setting that allows websites when FortiGuard cannot be reached to rate them, instead of blocking them.
DNS filtering: Rating and acting on the domain in a DNS query so bad domains are blocked at lookup time for any protocol, without TLS decryption.
Block at lookup: Preventing name resolution for an unwanted domain so the client never connects to it.
Safe search enforcement: Forcing search engines and some video sites into their family-safe mode so explicit results are filtered regardless of user settings.
Protocol independence: DNS filtering works for any application because it acts on the query, not on decrypted payloads.
Application control sensor: A profile of application/category actions attached to a firewall policy that identifies apps by FortiGuard signatures.
Category action: The action applied to a whole application category, such as blocking Peer-to-Peer, effective regardless of port.
Application override: A per-signature rule that sets a different action for one specific application than its category's action.
Filter override: A rule that selects applications by attributes (category, risk, technology, vendor) and applies an action to that set.
Flow vs proxy AV: Flow scans as packets pass with minimal buffering (fast); proxy buffers the whole file before forwarding (more features, more cost).
Signature database: FortiGuard-updated malware signatures the FortiGate matches files against; catches known threats but not brand-new ones.
Sandbox (FortiSandbox / cloud): An isolated environment that runs unknown files to detect malware by behaviour, catching zero-days signatures miss.
Content disarm and reconstruction (CDR): A proxy-only feature that strips active content from documents and rebuilds a clean file before delivery.
IPS sensor: A profile of selected signatures and actions attached to a firewall policy to detect and block attacks.
Signature filter: A rule that selects signatures by target, OS, application/protocol and severity so inspection stays focused.
Botnet C&C blocking: An IPS option using FortiGuard's database to block outbound connections to known command-and-control servers.
IPS fail-open: The setting that lets traffic pass uninspected when the IPS engine is overloaded (availability) versus dropping it (security).
DoS policy: A rule evaluated early at an interface ingress that enforces anomaly thresholds to drop or log flood and scan traffic before firewall policy lookup.
Anomaly sensor: A detector for a specific pattern (SYN flood, port scan, UDP/ICMP flood, session count) with a configurable threshold and action.
Threshold: The rate or count at which an anomaly triggers its action; set above normal peaks to avoid false positives.
Early evaluation: DoS policies run before firewall policies and most inspection, letting them shed floods cheaply.
Security (UTM) log: The log recording security-profile actions (AV, web filter, application control, IPS, DNS) with source, destination, signature and action.
FortiGuard connectivity: The FortiGate's ability to reach FortiGuard for signature and rating updates, which most security profiles depend on.
diagnose autoupdate versions: A CLI command showing each FortiGuard database's version, last update time and entitlement status.
Rating error: A web-filter symptom that appears when FortiGuard cannot be reached to categorize a site.

Domain 4: Routing (14%)

Exam tips

Policy routes are evaluated before the routing table. Within the table the order is longest match, then distance, then priority. Specificity (prefix length) always wins before distance.
Distance decides which routes are in the table (one active); priority decides preference among routes already in the table (all active). Use distance for a cold backup, priority for a hot standby.
Backup and higher-distance routes appear only in the database view, not the active routing table. Use routing-table all for active routes and the database keyword for everything known.
An RPF (reverse path) failure in a debug flow almost always means a missing return route for the source subnet via the ingress interface, common after asymmetric routing changes. Add the route.
A link monitor is what detects a dead path and removes the route, since a route otherwise stays up while its interface is up. Blackhole routes (high distance) stop traffic leaking when a tunnel drops.
Two SD-WAN gotchas: policies must reference the zone (not the member interface), and you must add a static default route pointing to the zone, or SD-WAN rules have no traffic to steer.
Probe a target that represents the real destination, not the local gateway, or the SLA will miss Internet-side loss. The SLA only measures; SD-WAN rules act on which members meet the target.
Best quality always chases the top metric even when the current link is fine; lowest cost (SLA) only switches when the cheap link fails the SLA. Match the strategy to the intent the question states.
Health-check shows the measurements and SLA pass/fail; service shows which member each rule picked. Check measurements first, since rules act on SLA state, then check how the rule used it.

Key terms

Policy route (PBR): A rule matched before the routing table that forces matching traffic out a specified interface/gateway, overriding destination-based routing.
Longest prefix match: The routing rule that the most specific (longest mask) route to a destination is preferred over less specific ones.
Administrative distance: A measure of trust in a route's source; among equal-prefix routes the lowest distance is installed as active.
Priority (static): A tie-breaker among equal-prefix, equal-distance routes; the lower value is preferred while both stay in the table.
Priority: Among equal-distance routes (all active), the lower priority value is preferred for forwarding while the others stay usable.
Floating static route: A backup static route given a higher distance so it stays out of the table until the primary route fails.
ECMP load-balancing method: How traffic is shared across equal-distance, equal-priority routes; the default is source-IP based to keep session affinity.
Routing table (RIB): The active routes currently used to forward traffic; shown by get router info routing-table all.
Routing database: All candidate routes the FortiGate knows, active and inactive; shown by get router info routing-table database.
Active vs inactive route: An active route is installed and forwarding; an inactive route (for example a higher-distance backup) waits in the database.
Standby/backup route: A route (often a floating static route) that stays in the database until the active route is removed.
Reverse path forwarding (RPF): An anti-spoofing check that drops packets whose source has no valid return route via the interface they arrived on.
Strict RPF: A mode requiring the best return route to the source to use the same interface the packet arrived on.
Feasible-path (loose) RPF: The default, more permissive mode that accepts the packet if any active return route to the source exists via the ingress interface, even if it is not the best route.
Asymmetric routing: A situation where traffic takes different paths each way, a common trigger for RPF drops when the return route is missing.
Link health monitor: An active probe (ping, HTTP, DNS, TCP) through an interface that withdraws the associated route when the path fails.
Route withdrawal on failure: Removing a static route from the table when its health monitor detects a dead path, letting a backup take over.
Blackhole route: A route that silently discards matching traffic, usually given a high distance so it activates only when the real route is gone.
Traffic leak prevention: Using a blackhole route so that when a tunnel/route drops, sensitive traffic is dropped instead of following the default route out.
SD-WAN member: A WAN interface or tunnel added to SD-WAN as a selectable path, with per-member settings like gateway and cost.
SD-WAN zone: A group of members that firewall policies and routes reference instead of the individual interfaces.
Zone reference in policy: After an interface becomes a member, policies select the SD-WAN zone, not the interface directly.
Route to the zone: A static (usually default) route pointing at the SD-WAN zone, required so the routing table hands traffic to SD-WAN.
Performance SLA: An SD-WAN health check that probes each member and measures latency, jitter and packet loss against targets.
Probe / probe server: The periodic test (ping, HTTP, DNS, TCP) sent to a reachable target to measure a member's quality.
Latency, jitter, packet loss: The three measured metrics: round-trip delay, variation in delay, and percentage of lost probes.
SLA target: Threshold values (for example max latency/jitter/loss) that decide whether a member currently meets the SLA.
Manual rule: Assigns matching traffic to specified members in order, ignoring SLA measurements.
Best quality: Selects the member with the best measured metric (latency, jitter, loss or bandwidth), always chasing the top score.
Lowest cost (SLA): Selects the cheapest member that currently meets the SLA target, moving off it only when it fails the SLA.
Maximize bandwidth (SLA) / implicit rule: Maximize bandwidth spreads traffic across all in-SLA members; the implicit rule is the catch-all for traffic matching no explicit rule.
diagnose sys sdwan health-check: Shows per-member SLA measurements (latency, jitter, loss) and whether each member meets the SLA target.
diagnose sys sdwan service: Shows each SD-WAN rule and which member(s) it currently selects, and in what order, based on strategy and SLA state.
SLA state: Whether a member currently meets its SLA target, which rules use to decide member eligibility.
Measurement-then-decision flow: Troubleshooting by first checking health-check (data) then service (how rules used the data).

Domain 5: VPN (14%)

Exam tips

Phase 1 up but phase 2 down almost always means mismatched phase 2 proposals, PFS/DH group, or selectors. And when a peer is behind NAT, remember UDP 4500 (NAT-T), not just UDP 500.
Prefer route-based (interface-mode) VPNs: the tunnel interface lets routes, policies, SD-WAN and ADVPN use it. Encryption strength is the same as policy-based, so the reason is flexibility, not stronger crypto.
The side with the unknown/dynamic address must initiate; the static side accepts it as a dial-up peer. Two dial-up peers can never connect because neither has an address to dial.
A tunnel showing up is not enough. You still need a route for the remote subnet via the tunnel interface and policies in both directions, and tunnel policies usually should not apply SNAT.
Redundant VPN failover needs both parts: different route distances/priorities to set primary vs backup, and DPD (or tunnel monitoring) to detect a dead tunnel so its route is withdrawn. DPD off breaks failover.
Hub-and-spoke needs n minus 1 tunnels; full mesh needs n(n-1)/2. ADVPN keeps hub-and-spoke's low configuration while giving on-demand direct spoke-to-spoke paths, so it scales without the mesh maintenance.
Use the gateway list for phase 1, the tunnel list for phase 2 and packet counters, and the IKE debug to see why negotiation fails. Nothing prints from the debug until you run diagnose debug enable.
On later 7.6 builds, SSL VPN tunnel mode is removed and web mode is renamed agentless VPN; FortiClient dial-up IPsec is the full remote-access method. Confirm remote-access coverage on your exam version.

Key terms

IKEv1 vs IKEv2: IKE versions for negotiating IPsec; IKEv2 is newer, uses fewer messages and is generally preferred. Both peers must use the same version.
Phase 1 vs phase 2: Phase 1 builds the authenticated IKE SA (secure channel); phase 2 builds the IPsec SA that encrypts user data.
Proposal / DH group / PFS: A proposal is the offered algorithm set; the DH group sets key-exchange strength; PFS runs a fresh DH per phase 2 key so one key's compromise does not expose others.
UDP 500 / 4500 (NAT-T): IKE uses UDP 500; when a peer is behind NAT, NAT traversal moves ESP traffic to UDP 4500.
Route-based (interface-mode) VPN: An IPsec VPN that creates a virtual tunnel interface usable by routes, firewall policies, SD-WAN and ADVPN.
Policy-based VPN: An IPsec VPN tied to a special encryption firewall policy rather than an interface; simpler but not scalable.
Tunnel interface: The virtual interface a route-based VPN produces, through which you route traffic and to which you apply policies.
Scalability/flexibility: Route-based VPNs support backup routes, dynamic routing, SD-WAN and ADVPN; policy-based do not.
Static peer: An IPsec peer with a known fixed public IP; each side configures the other's specific gateway address and either can initiate.
Dial-up (dynamic) peer: A phase 1 that accepts incoming tunnels from callers whose addresses are unknown in advance, used when one side has a dynamic IP or for many spokes.
Initiator vs responder: The peer with the unknown/dynamic address must initiate; the peer with the static address accepts (responds) as the dial-up server.
Peer ID / authentication: Identifiers and credentials (PSK or certificate) that let a dial-up server distinguish and authorize incoming callers.
Route via tunnel interface: A static route whose destination is the remote subnet and whose device is the IPsec tunnel interface, directing traffic into the tunnel.
Bidirectional policies: Firewall policies allowing traffic both from LAN to tunnel and from tunnel to LAN, so that either site can start connections (replies to a session are allowed statefully).
No SNAT for tunnel traffic: Tunnel policies normally do not apply source NAT so both LANs see each other's real addresses.
Up but no traffic: The symptom when a tunnel negotiates successfully but the route or policies are missing, so no data crosses it.
Redundant tunnels: Two or more tunnels over different paths so the VPN survives a single link or tunnel failure.
Route distance/priority for failover: Different administrative distances (or priorities) on the tunnels' routes make one primary and one backup.
Dead peer detection (DPD): Periodic liveness probes that detect an unresponsive peer, bring the tunnel down and let its route be withdrawn.
Tunnel monitoring: Link monitoring over a tunnel that detects a broken path and drives route changes for failover.
Hub and spoke: Each spoke tunnels only to a central hub (n minus 1 tunnels); spoke-to-spoke traffic passes through the hub.
Full mesh: Every site has a direct tunnel to every other (n times (n minus 1) divided by 2 tunnels); shortest paths but many tunnels.
Partial mesh: Direct tunnels only between selected site pairs, with the rest via the hub, balancing efficiency and count.
ADVPN (Auto-Discovery VPN): A hub-and-spoke design where spokes build direct short-cut tunnels on demand, giving mesh-like paths without manual full-mesh tunnels.
diagnose vpn ike gateway list: Shows phase 1 (IKE) gateways, their state, addresses, negotiated version/proposals and NAT-T status.
diagnose vpn tunnel list: Shows phase 2 (IPsec) SAs, selectors, proposals and encrypted/decrypted packet counters.
diagnose debug application ike -1: Verbose real-time logging of the IKE negotiation, revealing the exact reason a tunnel fails to establish.
Debug enable/disable: diagnose debug enable is required for debug output to print; diagnose debug disable turns it off afterward.
FortiClient dial-up IPsec: Remote-access VPN where FortiClient initiates an IPsec tunnel to a FortiGate dial-up server, which authenticates the user and assigns settings via mode-config.
Mode-config: The IKE mechanism that assigns an IP address and network settings to a dial-up/remote client when the tunnel comes up.
SSL VPN tunnel mode removal: In later FortiOS 7.6 builds, full-tunnel SSL VPN was removed, with IPsec (FortiClient) as the supported full remote-access path.
Agentless VPN: The renamed SSL VPN web mode: browser-based, clientless access to specific internal web/application resources through a portal.

Study FortiGate Admin for free
Lessons, quizzes, exam simulations and hands-on labs.

Open the FortiGate Admin study plan