Fortinet · security

Fortinet NSE4 FortiGate Security

FortiGate firewall configuration, security policies, VPN, authentication, and network protection fundamentals.

10Modules
30 hoursDuration
intermediateLevel
⚡ Practice the exam 🗺️ Open Cert Quest path ← All courses

Course Modules

🔨
Module 1
FortiGate Introduction & System Setup
2 lessons
NSE4 begins with the appliance itself: FortiOS as the unified OS, the SPU/NP/CP ASIC offload story, and the two deployment shapes — NAT/Route (default L3 gateway) vs Transparent (L2 bridge that slips inspection into an existing topology without renumbering). Initial setup means admin profiles, trusted hosts, interface roles, and a working FortiGuard reach via DNS + NTP.
1.1 FortiGate Platform Overview

Key Concepts

  • ASIC-based architecture: FortiGate appliances leverage Fortinet's custom SPU (Security Processing Unit) chips, including the NP (Network Processor) for hardware-accelerated packet forwarding and the CP (Content Processor) for offloading IPS, encryption, and content inspection tasks, delivering significantly higher throughput than software-only firewalls.
  • FortiOS operating system: The proprietary operating system running on all FortiGate devices provides a unified management interface for firewall, VPN, UTM, and SD-WAN features. FortiOS configuration is stored in a hierarchical text-based format and can be managed via the GUI, CLI, or REST API.
  • Deployment modes — NAT/Route vs Transparent: In NAT/Route mode the FortiGate acts as a Layer 3 gateway performing routing and address translation, which is the most common deployment. In Transparent mode it operates as a Layer 2 bridge, inserting security inspection into the network without requiring IP address changes on existing infrastructure.
  • FortiGate models and licensing: Fortinet offers appliances ranging from desktop units (FortiGate 40F/60F) to chassis-based data-center models (FortiGate 7000 series) and virtual machines (FortiGate-VM). FortiGuard subscription licenses enable services such as antivirus, IPS, web filtering, and application control signature updates.
  • Security Fabric integration: FortiGate serves as the core of the Fortinet Security Fabric, communicating with FortiAnalyzer, FortiManager, FortiSwitch, FortiAP, and other Fabric-connected devices to provide centralized visibility, coordinated threat response, and unified policy management across the entire network infrastructure.
Exam tip: Understand the difference between NP and CP processors and which traffic types each accelerates. Know that NAT/Route mode is the default and when to choose Transparent mode (e.g., inserting a FortiGate without changing the existing network topology).
1.2 Initial Configuration

Key Concepts

  • Administrative access and profiles: FortiGate supports multiple admin accounts with role-based access profiles (super_admin, prof_admin, custom profiles). Access can be restricted by trusted hosts, and two-factor authentication via FortiToken can be enforced for administrative logins via GUI (HTTPS) or CLI (SSH/console).
  • Interface configuration: Each FortiGate interface is assigned an IP address, administrative access protocols (HTTPS, SSH, ping, SNMP), and a role (LAN, WAN, DMZ, undefined). Interfaces can be physical ports, VLAN sub-interfaces, aggregate links (802.3ad), or software switches that bridge multiple ports into a single broadcast domain.
  • Dashboard and system settings: The FortiOS dashboard provides real-time widgets for system resources, license status, security alerts, and traffic statistics. System-level settings include hostname, time zone, DNS servers (essential for FortiGuard connectivity), and NTP configuration for accurate log timestamps.
  • Firmware management: Firmware upgrades follow a supported upgrade path documented in the Fortinet release notes. Administrators should always back up the configuration before upgrading, and the FortiGate supports dual firmware partitions so a previous firmware version can be booted if the upgrade causes issues.
Exam tip: Remember that the default admin account has no password and should be secured immediately. Know how trusted hosts restrict management access by source IP, and always verify the supported upgrade path before performing firmware updates.

🛡 Scenario — initial FortiGate setup from factory default

Task: A new FG-100F arrives factory-fresh. You need to set the management IP, change the admin password, set hostname, configure NTP, and verify connectivity before deploying in production.

Walk: 1) Connect a laptop to port1 (default management: 192.168.1.99). Access https://192.168.1.99. Login: admin / (no password). 2) System → Settings → change hostname to FW-HQ-01, set timezone, enable NTP (time.google.com). 3) System → Administrators → change admin password to a strong passphrase. 4) Network → Interfaces → set port1 IP to 10.0.0.1/24 (management VLAN). 5) execute ping 8.8.8.8 from CLI to verify WAN. 6) Backup config: System → Configuration → Backup.

NSE4 exam point: The default management IP is 192.168.1.99/24 on port1. Always change the admin password on first login. Factory reset via CLI: execute factoryreset.

Key takeaways
  • NAT/Route is the default (L3, doing routing + NAT); pick Transparent when you must drop a FortiGate into an existing L2 segment without IP changes. The exam pins this choice to "minimum disruption" wording.
  • Restrict admin access with trusted hosts (per-account source-IP allow-list) + role profiles (super_admin, prof_admin, custom) + FortiToken 2FA — never leave the default admin with no password.
  • FortiGuard needs DNS + NTP working before signatures + license features come online; broken DNS is the #1 reason a fresh FortiGate shows "license inactive" in the dashboard.
⚡ Mini-quiz — Drill NAT/Route vs Transparent triggers, NP/CP offload, trusted hosts, and FortiGuard prerequisites.
Quick quiz →
🛡️
Module 2
Firewall Policies
3 lessons
Firewall policies are the heart of the FortiGate. Each policy matches on source / destination / service / schedule / users, applies an action (Accept / Deny / IPsec / SSL VPN), and chains security profiles for deep inspection. Order matters — policies are evaluated top-down and the first match wins, so the implicit deny at the bottom never fires when a broader rule sits above it.
2.1 Policy Types & Matching

Key Concepts

  • Firewall policy components: Each policy is defined by incoming interface, outgoing interface, source address/user/group, destination address, schedule, and service. Traffic must match all criteria in a single policy to be permitted; if no policy matches, the implicit deny rule at the bottom of the policy list drops the traffic silently.
  • Address objects and groups: FortiGate uses address objects (subnet, IP range, FQDN, geography-based, ISDB) as building blocks for policies. Address groups aggregate multiple objects for easier policy management. FQDN objects resolve dynamically using DNS, and Internet Service Database (ISDB) objects identify well-known cloud services by IP range.
  • Schedules and services: Schedules define when a policy is active (one-time or recurring), allowing time-based access control. Service objects define protocols and ports (predefined services like HTTP/HTTPS, or custom TCP/UDP/SCTP definitions) that the policy will match.
  • Policy lookup and matching logic: FortiGate evaluates policies from top to bottom and uses the first match. The policy table can be viewed in sequence mode (ordered list) or interface pair mode (grouped by interface pairs). Understanding lookup order is critical for troubleshooting traffic that is unexpectedly allowed or denied.
Exam tip: The implicit deny policy at the end of the policy list has logging disabled by default. For troubleshooting, enable logging on the implicit deny to see what traffic is being dropped. Remember that policies are matched top-down and the first match wins.
2.2 Policy Actions & Inspection

Key Concepts

  • Accept action with security profiles: When a policy action is set to ACCEPT, traffic is forwarded and can optionally be inspected by attaching security profiles (antivirus, web filter, IPS, application control, DNS filter, etc.). Without security profiles, accepted traffic passes through without deep inspection.
  • Deny action behavior: The DENY action drops matching traffic. Unlike the implicit deny, an explicit deny policy can have logging enabled and can be placed strategically in the policy order to block specific traffic before broader allow rules are reached.
  • Inspection modes — flow-based vs proxy-based: Flow-based inspection examines packets as they stream through the FortiGate using pattern matching, offering higher throughput with lower latency. Proxy-based inspection buffers and reconstructs the full content (files, web pages) before scanning, providing deeper inspection capabilities such as content replacement and more thorough malware detection.
  • Security profile groups: Instead of attaching individual security profiles to each policy, administrators can create profile groups that bundle multiple security profiles together. This simplifies policy configuration and ensures consistent protection across multiple policies.
Exam tip: Know the trade-offs between flow-based and proxy-based inspection. Flow-based is faster and the default for most deployments, while proxy-based offers deeper inspection at the cost of performance. Security profiles have no effect unless explicitly attached to a policy.
2.3 Policy Ordering & Best Practices

Key Concepts

  • Top-down processing order: Policies are evaluated sequentially from top to bottom. More specific rules must be placed above more general rules to prevent the general rule from matching first. Moving a policy to the wrong position can inadvertently open or block access to services.
  • Policy IDs and sequence numbers: Each policy has a unique, immutable policy ID assigned at creation and a separate sequence number that determines its position in the evaluation order. Moving a policy changes its sequence number but not its ID; log entries reference the policy ID for correlation.
  • Logging and traffic shaping: Each policy can log traffic at session start, session end, or both, with UTM log entries generated by security profiles. Traffic shaping policies apply bandwidth limits (guaranteed and maximum) and priority queuing (high, medium, low) per policy, enabling QoS controls for critical applications.
  • Policy optimization tips: Regularly review policy hit counts to identify unused or shadow policies. Use the policy lookup tool (diagnose firewall proute list / policy match) to verify which policy a specific flow will hit. Consolidate overlapping policies and remove stale rules to maintain a clean, auditable rule base.
Exam tip: Use the diagnose firewall iprope lookup CLI command to test which policy matches specific traffic parameters. Zero-hit-count policies should be reviewed and removed if no longer needed. Always place more specific policies above general ones.

🛡 Scenario — creating an outbound internet access policy

Task: LAN users (192.168.10.0/24 on port2) need internet access through WAN (port1). Create the permitting policy with NAT, enable logging, and verify.

Walk: 1) Policy & Objects → Firewall Policy → Create New. 2) Incoming Interface: port2 (LAN); Outgoing Interface: port1 (WAN). Source: LAN_SUBNET. Destination: all. Service: ALL. Action: ACCEPT. 3) Enable NAT (Use Outgoing Interface Address). 4) Enable Log Allowed Traffic → All Sessions (for troubleshooting) or Security Events. 5) Enable an Application Control or Web Filter profile if needed. Click OK. 6) Verify: diag debug flow filter addr 192.168.10.10 then diag debug flow show function-name enable while pinging from a client — confirm the policy matches.

NSE4 exam point: Policies are matched top-down; first match wins. Always order specific rules before broad ones. The implicit deny at the bottom blocks everything not explicitly permitted.

Key takeaways
  • Top-down first-match evaluation: put the most specific policies on top, broad allows on the bottom. The implicit deny is the safety net, not the strategy.
  • A policy that allows traffic but applies no security profile is just a router rule — the inspection (AV, IPS, WebFilter) only happens when you attach the relevant profile.
  • Use policy ID + sequence grouping in FortiOS 7.x to keep large rule bases readable; the GUI hides this behind drag-and-drop but the CLI config firewall policy + move commands are the exam answer.
⚡ Mini-quiz — Drill policy match order, security-profile attachment, action types, and the implicit-deny behavior.
Quick quiz →
🔄
Module 3
Network Address Translation
2 lessons
NAT splits cleanly into Source NAT (translate the source on the way out — internal to internet, IP-pool or interface-IP-overload) and Destination NAT (translate the destination on the way in — VIPs publish an internal service on a public IP). Central NAT decouples NAT from policy; per-policy NAT is the default and easier to read.
3.1 Source NAT

Key Concepts

  • Overload IP pool (PAT): The default source NAT method translates multiple internal addresses to a single external IP using port address translation. FortiGate dynamically assigns source ports from a pool, allowing thousands of concurrent sessions to share one public IP. This is the most common NAT method for internet-bound traffic.
  • One-to-one IP pool: Maps each internal source IP to a unique external IP from the pool on a first-come, first-served basis. Unlike overload, the source port is preserved when possible. This is useful when external servers or applications require a consistent source IP-to-port mapping.
  • Fixed port range IP pool: Allocates a fixed block of ports per internal IP from the IP pool, ensuring deterministic NAT mappings. This method is required for carrier-grade NAT (CGNAT) scenarios and simplifies log correlation because each internal host always maps to the same external IP and port range.
  • Port block allocation: An extension of fixed port range that assigns a specific block size of ports (e.g., 128 ports) to each internal host. When the block is exhausted, a new block is allocated. This provides better traceability for ISPs and large enterprises that need to map sessions back to specific internal users.
  • Central SNAT vs per-policy NAT: FortiGate supports two SNAT configuration approaches. Per-policy NAT configures NAT settings directly within each firewall policy. Central SNAT uses a dedicated NAT table that is evaluated separately from the policy table, providing more granular and reusable NAT rules independent of security policies.
Exam tip: Know the four IP pool types and when to use each. Overload is the default; one-to-one preserves source ports; fixed port range provides deterministic mappings; port block allocation adds traceability. Central SNAT is configured under Policy & Objects > Central SNAT.
3.2 Destination NAT

Key Concepts

  • Virtual IPs (VIPs): A VIP maps an external IP address (and optionally a port) to an internal server's IP address. When traffic arrives at the FortiGate destined for the VIP's external IP, DNAT translates the destination to the mapped internal address before the firewall policy is evaluated. VIPs must be referenced in a firewall policy to allow the traffic.
  • Port forwarding: VIPs support port forwarding, which maps a specific external port (or port range) to a different internal port. For example, external port 8443 can be mapped to internal port 443, allowing public access to an internal HTTPS server on a non-standard external port.
  • VIP load balancing: FortiGate VIPs support server load balancing by mapping a single external IP to multiple internal servers. Load-balancing methods include static (round-robin, weighted), dynamic (least connections, least sessions), and HTTP host/URL-based distribution. Health monitors ensure traffic is only sent to responsive servers.
  • DNAT and firewall policy interaction: DNAT via VIP occurs before policy matching, so the firewall policy must use the VIP object as the destination address (not the internal server IP). The policy's destination interface should be the interface where the internal server resides. This two-step process (DNAT then policy check) is a common source of misconfiguration.
Exam tip: Remember that DNAT happens before the policy lookup. Always use the VIP object as the destination in your firewall policy, not the real internal server IP. If traffic is being dropped, verify that the policy references the VIP and that the correct interfaces are specified.

🛡 Scenario — DNAT to publish an internal web server

Task: An internal web server at 192.168.10.50:80 must be reachable from the internet on the FortiGate's WAN IP port 80.

Walk: 1) Policy & Objects → Virtual IPs → Create New. Name: VIP-WebServer. External Interface: port1 (WAN). External IP: WAN_IP. Mapped IP: 192.168.10.50. Enable Port Forwarding: External Port 80 → Map to Port 80. 2) Firewall Policy → Create New. Incoming: port1; Outgoing: port2; Source: all; Destination: VIP-WebServer; Service: HTTP; Action: ACCEPT. Enable logging. 3) Test: curl http://<WAN_IP> from an external host — should reach the internal server.

NSE4 exam point: VIPs are used for DNAT (inbound). For outbound NAT, use the NAT checkbox in the policy (SNAT). VIPs must be referenced in a policy destination to take effect — creating a VIP alone doesn't open traffic.

Key takeaways
  • SNAT modes: Use Outgoing Interface Address (PAT to the WAN IP — simplest), Dynamic IP Pool (overload / one-to-one / fixed-port), Static IP Pool (1:1 mapping). Pick by source-port preservation + public-IP availability.
  • DNAT via VIP object: configure once, then reference in policies. port-forward on the VIP narrows it to a specific external/internal port pair; without it, all ports forward.
  • Central NAT is a per-VDOM switch: enable it and NAT rules become independent of firewall policies. Off by default — the exam asks you to recognize when it's appropriate (NAT for multiple policies = central; NAT for one policy = per-policy).
⚡ Mini-quiz — Drill SNAT pool types, VIP/DNAT port-forwarding, and central vs per-policy NAT.
Quick quiz →
👤
Module 4
Firewall Authentication
2 lessons
Auth on FortiGate runs locally (built-in user db) or remote (LDAP, RADIUS, TACACS+, FSSO). Users get identified per session through a captive portal, transparent FSSO (Single Sign-On with AD), or explicit cert auth. Once identified, policies can match on user/group — turning a flat IP-based firewall into an identity-aware policy engine.
4.1 Local & Remote Authentication

Key Concepts

  • Local user accounts: FortiGate can store user credentials locally with passwords hashed in the device configuration. Local users are suitable for small deployments or guest access but do not scale well for enterprise environments. Each local user can optionally be assigned a FortiToken for two-factor authentication.
  • LDAP authentication: FortiGate integrates with LDAP directories (Active Directory, OpenLDAP) by querying the directory server to validate user credentials. The LDAP server object specifies the server IP, port (389/636), bind DN, base DN, and search filter. Secure LDAP (LDAPS on port 636) encrypts the authentication exchange.
  • RADIUS and TACACS+ authentication: RADIUS is widely used for network access authentication and supports attribute-value pairs for assigning user groups, VLANs, and other parameters. TACACS+ provides separate authentication, authorization, and accounting streams and encrypts the entire payload (unlike RADIUS, which only encrypts the password). Both protocols can be used as remote authentication servers in firewall policies.
  • FortiToken two-factor authentication: FortiToken (hardware or mobile app) generates time-based one-time passwords (TOTP) that are validated by the FortiGate. FortiToken Mobile uses push notifications for a streamlined user experience. Two-factor authentication can be enforced for admin access, VPN logins, and firewall policy authentication.
Exam tip: Understand the difference between RADIUS (encrypts only the password, uses UDP) and TACACS+ (encrypts the entire packet, uses TCP). Know that LDAP is used for credential validation while RADIUS/TACACS+ can also pass authorization attributes back to the FortiGate.
4.2 Authentication Policies & Methods

Key Concepts

  • Active authentication (captive portal): When a user's traffic matches a policy requiring authentication, the FortiGate redirects the user to a captive portal login page. The user must enter credentials before the firewall permits traffic. Active authentication supports local, LDAP, and RADIUS authentication and can be customized with branded portal pages.
  • Passive authentication with FSSO: Fortinet Single Sign-On (FSSO) monitors domain controller security event logs (or uses a DC agent/polling) to detect user logon events and automatically maps usernames to IP addresses. This eliminates the need for users to authenticate again at the firewall, providing a seamless experience while still enabling identity-based policies.
  • Guest portals and user groups: FortiGate supports guest user management with temporary accounts, sponsorship workflows, and self-registration portals. User groups can be local, remote (LDAP/RADIUS), or FSSO-based, and are referenced directly in firewall policies to enforce access control by identity rather than just IP address.
  • Authentication timeouts and exemptions: Authenticated sessions have configurable idle and hard timeouts. Exempt lists can be defined to bypass authentication for specific sources, destinations, or services (e.g., allowing Windows Update traffic without requiring user login). The diagnose firewall auth list command shows currently authenticated users and their groups.
Exam tip: FSSO is the preferred method in Active Directory environments because it requires no user interaction. Know the three FSSO detection methods: DC agent mode, polling mode (agentless via WMI/WinSecLog), and collector agent mode. Use diagnose debug authd fsso list to verify FSSO user mappings.

🛡 Scenario — captive portal for guest Wi-Fi authentication

Task: Guest users on VLAN 100 must authenticate through a captive portal before getting internet access. Use local users for simplicity.

Walk: 1) User & Authentication → User Definition → Create New → create a local user guest01 with a password. 2) User & Authentication → User Groups → Create New → group GuestUsers, add guest01. 3) Policy & Objects → Firewall Policy → on the guest outbound policy, set Security Mode = Captive Portal, Portal type = Authentication, User Groups = GuestUsers. 4) Guest opens browser → redirected to FortiGate captive portal → enters credentials → internet access granted for the session timeout period.

NSE4 exam point: Active authentication (captive portal, dialog) requires the user to explicitly provide credentials. Passive authentication (FSSO, RSSO) uses existing domain login events — no second prompt.

Key takeaways
  • FSSO = transparent SSO from AD via the FSSO Collector Agent (polled DC security logs) or DC Agent (push). No client install; great UX. Captive portal is the fallback when FSSO can't resolve a user.
  • LDAP for directory lookups + group memberships, RADIUS for AAA (auth + account + audit) including 2FA via RADIUS-challenge, TACACS+ for command-level admin authorization (Cisco shops).
  • Match a policy on user/group instead of source IP for true identity-based rules — the policy logs then show who initiated the session, not just where from.
⚡ Mini-quiz — Drill FSSO modes, LDAP vs RADIUS vs TACACS+ use-cases, and identity-based policy matching.
Quick quiz →
🔐
Module 5
SSL VPN
2 lessons
SSL VPN gives remote users tunnel-mode (full L3 like IPsec, requires FortiClient) or web-mode (bookmarks in the browser, no client install — but limited to web/RDP/SSH bookmarks). Pick by what the user must do once inside: full network access → tunnel; specific apps → web. Authentication piggybacks on the same LDAP/RADIUS stack as policies.
5.1 SSL VPN Modes

Key Concepts

  • Web mode: SSL VPN web mode provides clientless remote access through a web browser. Users authenticate via the SSL VPN portal and access internal resources (HTTP/HTTPS, RDP, SSH, SMB, FTP, VNC) through application bookmarks rendered in the browser. No client software installation is required, making it ideal for unmanaged devices and contractors.
  • Tunnel mode: SSL VPN tunnel mode creates a full network-layer VPN tunnel using the FortiClient application. The FortiGate assigns a virtual IP address from a configured pool to the client, and all traffic (or only specified traffic in split-tunnel mode) is routed through the encrypted tunnel, providing full network access as if the device were on the LAN.
  • Realms: SSL VPN realms allow a single FortiGate to host multiple SSL VPN portals on different URL paths, each with its own user groups, authentication settings, and portal design. This is useful for organizations that need separate VPN access for different departments, user types, or tenants.
  • Bookmarks and portal customization: Web-mode bookmarks define the internal resources available to users (URLs, RDP hosts, SSH servers, file shares). Portals can be customized with organization branding, and different portals can be assigned to different user groups to control which bookmarks, tunnel options, and widgets each group sees.
Exam tip: Web mode is clientless but limited to specific protocols through the portal; tunnel mode requires FortiClient but provides full Layer 3 network access. Know that tunnel mode uses a virtual adapter (ssl.root) on the FortiGate and requires a firewall policy from ssl.root to the internal interface.
5.2 SSL VPN Configuration

Key Concepts

  • Portal design and tunnel settings: SSL VPN configuration involves defining the listening interface, port (default 443), server certificate, and authentication method. Portal settings control whether tunnel mode, web mode, or both are enabled, along with the IP pool range for tunnel-mode clients and DNS server assignments.
  • Split tunneling vs full tunneling: Split tunneling routes only traffic destined for the corporate network through the VPN, while all other traffic (internet browsing) goes directly through the client's local connection. Full tunneling routes all traffic through the VPN for maximum security and visibility. Split tunnel is configured by defining specific routing entries pushed to the client.
  • Client integrity checking and host checks: FortiGate can enforce host-check policies that verify the remote device's security posture before granting VPN access. Checks include verifying that antivirus software is installed and running, the OS is up to date, specific registry keys exist, or custom software is present. Non-compliant devices can be denied access or placed into a restricted portal.
  • Authentication and access control: SSL VPN authentication can use local users, LDAP, RADIUS, SAML, or client certificates. Firewall policies must be created from the SSL VPN interface (ssl.root) to internal network interfaces, with source user/group matching to enforce identity-based access. Multi-factor authentication should always be enabled for SSL VPN access.
Exam tip: A common misconfiguration is forgetting to create the firewall policy from ssl.root to the internal interface. SSL VPN requires both the VPN settings configuration and matching firewall policies. Use diagnose vpn ssl list to view active SSL VPN sessions and troubleshoot connectivity.

🛡 Scenario — configuring SSL-VPN web mode for remote access

Task: Remote employees need to access an internal RDP server at 192.168.10.100 via a browser-based SSL VPN portal — no client software required.

Walk: 1) VPN → SSL-VPN Portals → Edit "full-access" (or create a new portal). Enable Web Mode. Add a bookmark: Type = RDP, Name = "Internal RDP", Remote Host = 192.168.10.100. 2) VPN → SSL-VPN Settings: Enable SSL-VPN on WAN interface, set Listen Port (default 443 or 10443), Authentication/Portal Mapping: map SSLVPNUsers group to full-access portal. 3) Create a firewall policy: ssl.root → LAN; Source = SSLVPNUsers group + SSL-VPN tunnel range; Destination = 192.168.10.100; Service = RDP; Action = ACCEPT. 4) Test: browse to https://<WAN_IP>:10443, log in, click the RDP bookmark.

NSE4 exam point: Web mode = browser only (portal). Tunnel mode = FortiClient installs a virtual adapter — gives full network access to the internal subnet, not just published bookmarks.

Key takeaways
  • Tunnel mode = L3 access, needs FortiClient + a routable IP from the SSL VPN pool. Web mode = portal with bookmarks (HTTP, RDP via HTML5, SSH), no client install, far more restricted.
  • Split tunneling controls what traffic enters the VPN: on = only corporate subnets (saves bandwidth, breaks DLP), off = everything (full inspection at HQ, hairpins internet via WAN). The exam asks you to match the choice to the constraint.
  • SSL VPN realms let one FortiGate host multiple portal experiences (employees / contractors / partners) on the same IP, each with its own auth + bookmark set, addressed via URL path.
⚡ Mini-quiz — Drill tunnel vs web mode triggers, split tunneling trade-offs, and realm scoping.
Quick quiz →
🔒
Module 6
IPsec VPN
3 lessons
IPsec is the site-to-site workhorse: IKE negotiates the SAs in two phases, ESP carries the encrypted payload. Phase 1 establishes the secure channel (main vs aggressive mode), Phase 2 sets up the actual data SAs (proxy IDs / selectors). NSE4 tests the dial-up shape too — branches with dynamic IPs initiating to a static HQ.
6.1 IPsec Fundamentals

Key Concepts

  • IKEv1 vs IKEv2: Internet Key Exchange version 1 uses either Main Mode (6 messages for identity protection) or Aggressive Mode (3 messages, faster but less secure) for Phase 1 negotiation. IKEv2 simplifies the exchange to 4 messages, supports MOBIKE for seamless roaming, built-in NAT traversal, and is more resilient to denial-of-service attacks. FortiGate supports both versions.
  • Phase 1 negotiation: Phase 1 establishes the IKE Security Association (SA) by negotiating encryption algorithm (AES-128/256), authentication method (pre-shared key or certificate), hash algorithm (SHA-256/512), Diffie-Hellman group (DH group 14, 19, 20, 21), and SA lifetime. The result is a secure channel used to negotiate Phase 2 parameters.
  • Phase 2 negotiation: Phase 2 uses the IKE SA from Phase 1 to negotiate the IPsec SA parameters, including the encryption and authentication algorithms for data traffic, PFS (Perfect Forward Secrecy) DH group, SA lifetime, and the proxy IDs (source and destination subnets). Each Phase 2 SA defines a bidirectional tunnel for a specific traffic selector.
  • ESP and AH protocols: Encapsulating Security Payload (ESP, IP protocol 50) provides confidentiality (encryption), integrity, and optional authentication, and is the protocol used in virtually all modern IPsec deployments. Authentication Header (AH, IP protocol 51) provides integrity and authentication but not encryption and is rarely used. ESP in tunnel mode encapsulates the entire original IP packet inside a new IP header.
  • NAT Traversal (NAT-T): When IPsec peers are behind NAT devices, ESP packets cannot pass through NAT because there are no port numbers. NAT-T encapsulates ESP inside UDP port 4500, allowing the traffic to traverse NAT devices. FortiGate enables NAT-T automatically when it detects a NAT device in the path during IKE negotiation.
Exam tip: Know the message exchange counts: IKEv1 Main Mode = 6 messages, Aggressive Mode = 3 messages, IKEv2 = 4 messages (IKE_SA_INIT + IKE_AUTH). Understand that PFS in Phase 2 generates new keys independent of Phase 1, providing stronger security at a slight performance cost.
6.2 Site-to-Site VPN

Key Concepts

  • Route-based vs policy-based VPN: Route-based VPNs create a virtual IPsec interface and use static routes or dynamic routing protocols to direct traffic into the tunnel, offering greater flexibility for complex topologies. Policy-based VPNs define the tunnel within the firewall policy itself and do not create a virtual interface, making them simpler but less flexible. Route-based is the recommended approach in most scenarios.
  • Redundant VPN configurations: FortiGate supports multiple Phase 1 configurations to the same or different remote gateways for failover. Dead peer detection (DPD) monitors tunnel health and triggers failover to a backup tunnel when the primary peer is unreachable. Priority-based or weighted ECMP routing can distribute traffic across multiple active tunnels.
  • ADVPN (Auto-Discovery VPN): ADVPN enables dynamic, on-demand spoke-to-spoke tunnels in a hub-and-spoke topology. Initial traffic flows through the hub, which triggers the spokes to negotiate a direct tunnel between them, reducing latency and hub bandwidth consumption. ADVPN uses shortcut routes advertised by the hub via dynamic routing protocols (typically BGP or OSPF).
  • VPN overlays and SD-WAN integration: IPsec VPN tunnels are commonly used as SD-WAN overlay members. FortiGate SD-WAN rules can steer application traffic across multiple VPN tunnels based on performance SLAs (latency, jitter, packet loss), providing application-aware path selection across site-to-site connections.
Exam tip: Route-based VPN creates a virtual interface (e.g., vpn_phase1_name) that appears in the routing table and can participate in dynamic routing. Policy-based VPN does not create an interface and encrypts traffic based solely on the policy match. Always prefer route-based for production deployments.
6.3 Dial-up VPN & Troubleshooting

Key Concepts

  • Dial-up IPsec VPN: Dial-up VPN allows remote clients (FortiClient, third-party IPsec clients) to connect to the FortiGate without requiring a static IP address. The FortiGate Phase 1 configuration uses "Dialup User" as the remote gateway type, and mode-config assigns virtual IP addresses, DNS servers, and split-tunnel routes to connecting clients.
  • FortiClient configuration: FortiClient is Fortinet's endpoint VPN client that supports both IPsec and SSL VPN connections. Administrators can deploy pre-configured VPN profiles via FortiClient EMS (Enterprise Management Server) or export VPN settings from the FortiGate. FortiClient supports certificate-based authentication, XAuth, and two-factor authentication.
  • IKE debug and troubleshooting: The primary troubleshooting command is diagnose debug application ike -1 (with diagnose debug enable), which outputs real-time IKE negotiation messages. Common failure causes include mismatched Phase 1/2 proposals, incorrect pre-shared keys, proxy ID mismatches, and NAT issues. The diagnose vpn ike gateway list and diagnose vpn tunnel list commands show SA status and traffic counters.
  • VPN monitoring and logs: The FortiGate IPsec Monitor (under VPN > IPsec Monitor in the GUI) displays tunnel status, uptime, incoming/outgoing bytes, and Phase 2 selectors. VPN event logs record tunnel establishment, rekeying, and failure events. SNMP traps can be configured to alert on tunnel state changes for integration with network management systems.
Exam tip: When troubleshooting IPsec, always start with diagnose debug application ike -1 and look for proposal mismatch, authentication failure, or proxy ID mismatch errors. Verify that Phase 1 proposals (encryption, hash, DH group) and Phase 2 proposals (encryption, hash, PFS) match on both peers exactly.

🛡 Scenario — site-to-site IPsec VPN between two FortiGates

Task: Connect HQ (192.168.1.0/24) to Branch (10.10.10.0/24) via IPsec VPN. Both sites have FortiGate firewalls with static public IPs.

Walk (HQ side): 1) VPN → IPsec Wizard → Site to Site. Remote gateway: Branch WAN IP. Authentication: Pre-Shared Key S3cur3Phr4se!. Local subnet: 192.168.1.0/24. Remote subnet: 10.10.10.0/24. 2) Wizard creates the Phase 1, Phase 2, and route automatically. 3) Add a firewall policy: LAN → Branch-IPsec interface; Source = HQ LAN; Destination = Branch LAN; Action = ACCEPT (and reverse). Repeat mirror config on Branch FortiGate. 4) Verify: get vpn ipsec tunnel summary → tunnel should show "up". Ping 10.10.10.1 from HQ LAN client.

NSE4 exam point: Phase 1 = IKE negotiation (authentication + encryption parameters). Phase 2 = defines the traffic selectors (which subnets). If the tunnel stays down, check that Phase 1 and Phase 2 parameters match on both ends.

Key takeaways
  • Phase 1 = authenticate the peers (PSK or cert) + agree on encryption/hash/DH group. Phase 2 = define the actual traffic selectors (which subnets) + their crypto. Mismatched proxy-IDs are the #1 "tunnel up but no traffic" cause.
  • Main mode (6 packets, identity-protected, requires fixed IPs both sides) vs aggressive mode (3 packets, identity in clear, supports dial-up). Use aggressive only when one peer has a dynamic IP.
  • Dial-up uses an FGT-as-server with multiple dial-up clients connecting; identify them by FQDN or peer ID since the source IP can't be a selector. Pre-shared key per peer or X.509 cert.
⚡ Mini-quiz — Drill IKE phase 1 vs 2, main vs aggressive triggers, dial-up identification, and proxy-ID mismatch symptoms.
Quick quiz →
🛡
Module 7
Security Profiles
3 lessons
Security profiles are where FortiGate stops being a router. Bundle them onto a policy: Antivirus (flow vs proxy mode), IPS (signatures + anomaly), Web Filter (FortiGuard categories + URL filter), Application Control (signature-matched app IDs), DNS Filter (block at name resolution). Each profile attaches independently — combine to taste.
7.1 Antivirus & IPS

Key Concepts

  • Flow-based antivirus scanning: In flow-based mode, the FortiGate inspects file content as it streams through the device using pattern matching against the FortiGuard antivirus signature database. This approach offers high performance and low latency but cannot reconstruct files for full emulation. It detects malware signatures, grayware, and known malicious file hashes in real time.
  • Proxy-based antivirus scanning: Proxy-based AV buffers the entire file before scanning, enabling full file reconstruction, archive extraction (zip, rar, tar), and sandbox submission for zero-day threat analysis. This mode supports file size limits, replacement messages for blocked content, and external scanning via FortiSandbox integration for advanced threat detection.
  • Intrusion Prevention System (IPS): The FortiGate IPS engine matches network traffic against thousands of signatures that detect known exploits, protocol anomalies, and vulnerability-based attacks. IPS signatures are classified by severity (critical, high, medium, low, info) and can be configured to monitor, block, or reset offending sessions. Custom IPS signatures can be written for organization-specific threats.
  • Protocol options and inspection ports: Protocol options profiles define which protocols (HTTP, FTP, SMTP, POP3, IMAP, CIFS) the FortiGate inspects and on which ports. Non-standard ports can be added to ensure that traffic running on unusual ports still receives inspection. Oversized files and sessions exceeding buffer limits can be passed, blocked, or logged based on profile configuration.
Exam tip: Flow-based AV is faster but cannot extract archives or submit files to a sandbox. Proxy-based AV provides deeper analysis at the cost of latency. IPS signatures with action set to "default" will use the vendor-recommended action (monitor or block) for each signature.
7.2 Web Filtering

Key Concepts

  • FortiGuard category-based filtering: FortiGuard maintains a cloud-based URL database with over 80 categories (social networking, gambling, malware, phishing, adult content, etc.). The FortiGate queries FortiGuard in real time to classify URLs and enforces allow, block, monitor, warn, or authenticate actions per category. Category ratings can be overridden locally.
  • Static URL filters: Administrators can define explicit URL filter entries that override category-based decisions. URL filters support simple URLs, wildcard patterns, and regular expressions. An explicit block or allow entry for a specific URL takes precedence over the FortiGuard category rating, enabling fine-grained exceptions.
  • Content filters and safe search: Web filtering profiles can block pages containing specific words or patterns through web content filters. Safe search enforcement forces search engines (Google, Bing, YouTube) to use their restricted modes, filtering out explicit content from search results. FortiGuard search engine options can enforce this via DNS or header injection.
  • Web filter quotas and overrides: Quota-based filtering allocates a time or data allowance per category per user (e.g., 30 minutes of social media per day). Once the quota is exhausted, access is blocked until the next reset period. Administrators can also define override groups that allow authorized users to bypass specific category blocks after re-authenticating.
Exam tip: FortiGuard web filter requires an active subscription license and DNS connectivity for category lookups. The local URL filter is checked before the FortiGuard category rating, so explicit allow/block entries always take priority. Know the difference between "warn" (user can proceed after acknowledgment) and "block" (access denied).
7.3 Application Control & DNS Filtering

Key Concepts

  • Application signatures and categories: FortiGate application control uses deep packet inspection to identify over 4,000 applications regardless of port, protocol, or encryption. Applications are organized into categories (collaboration, cloud IT, social media, P2P, video/audio, VPN, etc.) with actions of allow, monitor, block, or traffic shape. Signature updates are delivered via FortiGuard.
  • Internet Service Database (ISDB): The ISDB is a built-in database of well-known internet services (Office 365, AWS, Google Workspace, Salesforce, etc.) defined by IP ranges and ports. ISDB entries can be used directly in firewall policies as destination objects, enabling precise control over cloud service access without manually maintaining IP lists that change frequently.
  • SSL deep inspection for application control: Many applications use HTTPS encryption, which prevents the FortiGate from identifying them via payload inspection. SSL deep inspection decrypts the traffic, applies application control signatures, and re-encrypts it before forwarding. Without deep inspection, application control relies on the SSL certificate's Common Name (CN) or SNI for identification, which is less granular.
  • DNS filter profiles: DNS filtering inspects DNS queries passing through the FortiGate and blocks resolution of domains categorized as malicious, phishing, botnet C&C, or other undesirable categories. DNS filtering works even for HTTPS traffic without requiring SSL inspection, since it blocks at the DNS resolution stage before any encrypted connection is established.
Exam tip: Application control needs SSL deep inspection to identify encrypted applications by payload. Without it, identification falls back to certificate CN/SNI. DNS filtering is effective against encrypted threats because it blocks domains at the DNS layer, before the encrypted session begins. Know that ISDB objects simplify policy creation for cloud services.

🛡 Scenario — blocking malware downloads with an AV + Web Filter profile

Task: Users are downloading executable files from file-sharing sites. Configure a security profile combination to block these and log the events.

Walk: 1) Security Profiles → AntiVirus → Create New. Enable scanning for HTTP, HTTPS (requires SSL inspection). Set action on virus = Block. 2) Security Profiles → Web Filter → Create New. Enable FortiGuard category blocking. Block categories: Malicious Websites, Hacking, Peer-to-Peer. Block URLs matching *.torrent. 3) Apply both profiles to the LAN → WAN firewall policy (edit the policy, attach AV profile and Web Filter profile). 4) Verify: attempt to browse to a blocked category → FortiGate returns a block page. Attempt to download an EICAR test file → blocked by AV.

NSE4 exam point: Security profiles (AV, Web Filter, IPS, App Control, DNS Filter) are only active when attached to a firewall policy. Creating a profile without attaching it does nothing.

Key takeaways
  • Flow mode AV/IPS scans as packets pass (lower latency, lower detection); proxy mode buffers and reconstructs (higher accuracy, higher latency). Default is flow; pick proxy when you need full file scanning.
  • Web Filter categorizes by FortiGuard's URL database; you can override a category for a specific URL via the static URL filter. App Control matches on protocol behavior, not port — that's how it catches apps tunneled over 443.
  • DNS Filter blocks at the resolver layer — fast, low-overhead, and stops the connection before it even forms. Pair it with Web Filter for defense in depth: DNS blocks the lookup, Web Filter blocks if a hard-coded IP bypasses DNS.
⚡ Mini-quiz — Drill flow vs proxy AV, Web Filter override, App Control vs port-based rules, and DNS Filter placement.
Quick quiz →
🔎
Module 8
SSL Inspection
2 lessons
TLS hides what your other profiles want to scan. Two inspection modes: Certificate Inspection (read the SNI/cert only — light, no MITM, can't see payload) vs Deep Inspection (full MITM — re-sign every cert with the FortiGate CA so endpoints must trust it). Deep is required for AV / IPS on HTTPS traffic; cert-only is enough for URL filtering.
8.1 Certificate Inspection vs Deep Inspection

Key Concepts

  • Certificate inspection mode: In certificate inspection mode the FortiGate examines only the server certificate metadata (Common Name, Subject Alternative Name, issuer, validity) and the SNI in the TLS Client Hello, without decrypting the session payload. This allows URL filtering and application identification based on the domain name while preserving end-to-end encryption. It generates no certificate warnings on client browsers.
  • Full SSL deep inspection: Deep inspection (also called man-in-the-middle or SSL proxy inspection) decrypts inbound and outbound HTTPS traffic by presenting a FortiGate-generated certificate to the client. The FortiGate decrypts the traffic, applies security profiles (AV, IPS, web filter, DLP), and re-encrypts it to the destination server. This provides full visibility into encrypted traffic but requires the FortiGate CA certificate to be trusted by client devices.
  • CA certificate deployment: For deep inspection to work without browser warnings, the FortiGate's CA certificate must be distributed to all client devices and added to their trusted certificate stores. In enterprise environments this is typically accomplished via Active Directory Group Policy Objects (GPO), MDM solutions, or manual installation. The default Fortinet_CA_SSL certificate is unique per device.
  • SSL inspection exemptions: Certain applications (banking, healthcare portals, certificate-pinned apps) may break under deep inspection. FortiGate allows administrators to define exemption lists by address, FQDN, category, or wildcard to bypass deep inspection for specific destinations. FortiGuard maintains a recommended exemption list for commonly affected services.
Exam tip: Certificate inspection does not generate browser warnings but only sees certificate-level information. Deep inspection sees the full payload but requires CA certificate trust. Applications using certificate pinning (e.g., banking apps, Microsoft updates) will fail under deep inspection and must be exempted.
8.2 SSL Inspection Profiles

Key Concepts

  • Outbound SSL inspection (protecting clients): Outbound deep inspection protects internal users browsing the internet. The FortiGate intercepts the client's TLS handshake, establishes its own session with the destination server, and presents a re-signed certificate to the client. This profile is applied to policies where internal users access external HTTPS resources.
  • Inbound SSL inspection (protecting servers): Inbound inspection (SSL offloading) decrypts traffic destined for an internal server by importing the server's real SSL certificate and private key into the FortiGate. The FortiGate terminates the SSL session, inspects the decrypted content with security profiles, and forwards the traffic to the server in clear text or re-encrypted. This protects web servers from encrypted attacks.
  • Trust chain and certificate validation: The FortiGate validates the server certificate chain during deep inspection, checking for expiration, revocation (CRL/OCSP), self-signed certificates, and untrusted CAs. Administrators can configure how to handle invalid certificates: block the connection, allow with a warning replacement page, or allow silently. Proper trust chain validation prevents users from reaching fraudulent or compromised sites.
  • Performance considerations: SSL deep inspection is CPU-intensive, particularly for high volumes of concurrent HTTPS sessions. FortiGate models with CP (Content Processor) ASIC chips offload SSL/TLS processing to hardware. Administrators should monitor CPU utilization and session counts when enabling deep inspection and may need to exempt high-bandwidth, low-risk traffic to balance security with throughput.
Exam tip: Inbound inspection requires the server's private key to be loaded on the FortiGate; outbound inspection uses the FortiGate's own CA certificate. Use diagnose test application ssl and hardware acceleration counters to monitor SSL inspection performance. CP processors significantly improve deep inspection throughput.

🛡 Scenario — enabling certificate inspection for HTTPS traffic

Task: The Web Filter is not blocking HTTPS sites because traffic is encrypted. Enable SSL inspection so the FortiGate can apply security profiles to HTTPS.

Walk: 1) Security Profiles → SSL/SSH Inspection → Create New. Choose Certificate Inspection (reads the SNI and certificate CN without decrypting the payload). This lets Web Filter apply category-based blocking to HTTPS without a MitM certificate. 2) Alternatively, choose Full Inspection (deep inspection / MitM): FortiGate re-signs the certificate using its own CA. Push the FortiGate CA certificate to all client browsers via GPO so they trust it. 3) Attach the SSL inspection profile to the LAN → WAN policy alongside the Web Filter and AV profiles.

NSE4 exam point: Certificate inspection = read metadata only, no decryption (limited visibility). Full inspection = decrypt, inspect, re-encrypt (full visibility but requires CA trust distribution). Financial and banking sites should be exempt from full inspection to avoid breaking TLS pinning.

Key takeaways
  • Certificate Inspection = no client install needed, only checks SNI/cert validity. Use when you only need web-category filtering of HTTPS sites.
  • Deep Inspection = full MITM; the FortiGate intermediate CA must be pre-installed on every endpoint, otherwise users see a cert warning on every site.
  • Exempt high-risk categories (banking, health) from deep inspection — legal + UX both win. Configure exemptions per profile by category, address, or FQDN.
⚡ Mini-quiz — Drill cert vs deep inspection triggers, CA-distribution prerequisites, and exemption strategies.
Quick quiz →
📊
Module 9
Logging & Monitoring
2 lessons
Logging answers "what just happened and why". FortiGate writes to local memory/disk by default; production sends to FortiAnalyzer (long-term analytics + reports) or syslog. FortiView is the real-time dashboard layered on top — top sources, top destinations, top apps, top threats — pivotable into the matching policy or session.
9.1 Log Types & Destinations

Key Concepts

  • Traffic logs: Traffic logs record every session that passes through the FortiGate, including source/destination IP, port, protocol, policy ID, bytes sent/received, duration, and NAT information. Traffic logs can be generated at session start, session end, or both. They are essential for forensic analysis, compliance auditing, and bandwidth monitoring.
  • Event logs: Event logs capture system-level activities such as administrator logins, configuration changes, HA failover events, VPN tunnel state changes, DHCP lease operations, and system reboots. Event logs are critical for change management auditing and identifying unauthorized administrative actions.
  • Security logs (UTM logs): Security logs are generated by security profiles and include antivirus detections, IPS alerts, web filter blocks, application control events, DNS filter blocks, and email filter actions. Each security log entry references the triggering policy ID and provides details about the threat (signature name, severity, action taken).
  • Log destinations: FortiGate supports multiple simultaneous log destinations: local disk (on models with SSD/HDD), memory buffer (volatile, limited capacity), FortiAnalyzer (dedicated log management and analytics appliance), FortiCloud (cloud-hosted logging service), and syslog servers (for integration with third-party SIEM platforms). FortiAnalyzer is the recommended destination for enterprise deployments.
  • Log severity levels and filtering: Logs are classified by severity: emergency, alert, critical, error, warning, notification, information, and debug. Administrators can filter which severity levels are sent to each destination, reducing storage requirements while ensuring critical events are always captured. Log rate limiting prevents log storms from overwhelming storage.
Exam tip: Memory logging is volatile and lost on reboot; disk logging persists but has limited capacity. FortiAnalyzer is Fortinet's recommended solution for long-term log storage and reporting. Know the three main log types (traffic, event, security) and which activities generate each type.
9.2 FortiView & Alert Management

Key Concepts

  • FortiView real-time monitoring: FortiView is the FortiGate's built-in traffic analytics dashboard that provides real-time and historical views of top sources, destinations, applications, threats, web sites, and cloud applications. FortiView uses drill-down navigation, allowing administrators to click from a high-level summary down to individual session details and log entries.
  • Threat map and policy hits: The FortiView threat map visualizes the geographic origin of detected threats in real time. Policy hit count monitoring shows how many sessions each firewall policy has matched, helping administrators identify the most-used rules, unused policies, and potential misconfigurations. These visualizations aid in both operational monitoring and policy optimization.
  • Automated email alerts: FortiGate can send email alerts when specific events occur, such as IPS critical-severity detections, HA failover, admin login failures, or system resource thresholds being exceeded. Alert email configuration requires an SMTP server and recipient list, and filters control which event types and severity levels trigger notifications.
  • SNMP traps and automation stitches: FortiGate supports SNMP v1/v2c/v3 for integration with enterprise network management systems (NMS). SNMP traps send asynchronous notifications on events like interface down, VPN tunnel changes, and high CPU usage. Automation stitches combine triggers (log events, SNMP, schedules) with actions (email, webhook, CLI script, cloud function) for automated incident response workflows.
Exam tip: FortiView requires logging to be enabled (disk or FortiAnalyzer) to display historical data. Automation stitches are configured under Security Fabric > Automation and are a powerful way to create automated response playbooks. Know that SNMP v3 provides authentication and encryption, while v1/v2c transmit community strings in clear text.

🛡 Scenario — diagnosing a blocked connection with traffic logs

Task: A user reports they cannot reach an internal server at 10.0.0.50:443. You need to determine whether the FortiGate is blocking the traffic and which policy is responsible.

Walk: 1) Log & Report → Forward Traffic. Filter by Source IP = user's IP, Destination IP = 10.0.0.50. Find entries with Action = Deny. Note the Policy ID in the log entry. 2) Policy & Objects → Firewall Policy → find the policy with that ID → check source/destination/service. 3) If no log entry exists, traffic may not be reaching the FortiGate. Run a sniffer: diag sniffer packet port1 "host 10.0.0.50" 4 10 l. 4) If traffic reaches but is being denied by an implicit deny, create the correct permitting policy above the implicit deny.

NSE4 exam point: The implicit deny does NOT log by default. Enable "Log Violation Traffic" in System → Settings to see denied traffic in the logs. Without this, denied traffic is invisible to Log & Report.

Key takeaways
  • Log destinations cascade: memory (fast, volatile, default) → disk (if model has one) → FortiAnalyzer/syslog (production). Always send to FortiAnalyzer in production — local disk wears out and rotates aggressively.
  • Log severity scale 0–7 (emergency → debug); set the threshold per destination to control noise. Production rule: WARNING+ to FAZ, NOTICE+ to disk, DEBUG only on demand.
  • FortiView is built on the same logs but pivoted: click a "top source" → drill into its policies → into specific sessions. The exam asks you to recognize this as the troubleshooting flow, not log search.
⚡ Mini-quiz — Drill log destinations, severity tuning, FortiView pivot paths, and FAZ vs syslog selection.
Quick quiz →
⚖️
Module 10
High Availability
2 lessons
HA pairs (or clusters up to 4) protect against single-FortiGate failure. Active-Passive (one box forwards, others stand by — simpler) vs Active-Active (load balanced — only for stateful sessions Fortinet supports). HA uses dedicated heartbeat links + virtual MAC addresses so the upstream/downstream switches see a stable next-hop even after failover.
10.1 HA Modes

Key Concepts

  • Active-passive HA: In active-passive mode, one FortiGate processes all traffic (the primary) while the other unit (the subordinate) stands by in a hot-standby state. If the primary fails, the subordinate takes over within sub-second to a few seconds, assuming the primary's IP and MAC addresses. This mode provides straightforward redundancy with no load distribution.
  • Active-active HA: In active-active mode, both FortiGate units process traffic simultaneously. The primary distributes sessions to the subordinate using a load-balancing algorithm. While both units handle traffic, the primary is responsible for all management functions and configuration synchronization. Active-active mode maximizes throughput but adds complexity to session handling.
  • FortiGate Clustering Protocol (FGCP): FGCP is the proprietary protocol that manages FortiGate HA clusters. It handles heartbeat monitoring, configuration synchronization, session synchronization, and failover coordination. FGCP runs over dedicated heartbeat interfaces and ensures that both units maintain identical configurations, firmware versions, and license entitlements at all times.
  • Session pickup: Session pickup synchronizes the session table between HA peers so that active sessions (TCP, UDP, ICMP, IPsec, and expectation sessions) survive a failover event without being dropped. TCP sessions resume without requiring retransmission, and VPN tunnels remain established. Session pickup must be explicitly enabled and configured, as it generates additional heartbeat traffic.
Exam tip: Active-passive is simpler and recommended for most deployments. Active-active provides higher throughput but only the primary handles certain traffic types (e.g., proxy-based inspection). Session pickup is critical for seamless failover but consumes additional bandwidth on the heartbeat link. Both HA peers must run the same firmware version and have matching licenses.
10.2 HA Configuration

Key Concepts

  • Heartbeat interfaces: At least one dedicated interface must be configured for HA heartbeat communication, carrying FGCP hello packets, configuration synchronization, and session table updates. For redundancy, two heartbeat interfaces should be configured on separate physical links. Heartbeat traffic is encrypted using a group password to prevent unauthorized devices from joining the cluster.
  • HA priorities and election: The primary unit is elected based on a priority value (0-255, higher wins), number of monitored interfaces that are up, HA uptime, and serial number (as a tiebreaker). Administrators set the priority to control which unit becomes primary. Override mode forces re-election when a higher-priority unit comes back online after a failure.
  • Failover behavior and monitoring: FortiGate HA monitors heartbeat links, configured monitored interfaces, and remote link monitoring targets (via ping to upstream routers). If monitored interfaces go down, the unit's effective priority is reduced, triggering a failover. The diagnose sys ha status command shows cluster state, and execute ha manage allows CLI access to the subordinate unit from the primary.
  • Firmware upgrades in HA and load balancing: FortiGate supports uninterruptible firmware upgrades in HA mode: the subordinate is upgraded first, then a failover occurs, and the former primary is upgraded, minimizing downtime to a single failover event. Virtual MAC addresses used by the cluster ensure that upstream and downstream devices do not need ARP table updates during failover, providing transparent recovery to the network.
Exam tip: Always use two heartbeat interfaces for redundancy. Know the election criteria order: override setting, priority value, monitored interface count, HA uptime, serial number. Use diagnose sys ha status to check cluster health and execute ha manage to access the subordinate CLI. Virtual MAC addresses prevent ARP issues during failover.

🛡 Scenario — configuring Active-Passive HA between two FG-100F units

Task: Deploy two FG-100F units in Active-Passive HA. The primary handles all traffic; the secondary takes over within seconds if the primary fails.

Walk: 1) On Primary: System → HA → Mode = Active-Passive. Group Name: HQ-HA. Password: ha-secret-pw. Priority: 200 (higher = preferred primary). Enable session sync. Connect HA heartbeat cables to dedicated heartbeat interfaces (HA1/HA2). 2) On Secondary: identical config but Priority = 100. 3) After a few seconds, get system ha status shows one Master and one Slave. 4) Failover test: unplug a WAN cable on the primary. Secondary promotes to Master within 1–3 seconds. Reconnect primary → it rejoins as Slave and syncs config automatically.

NSE4 exam point: In A-P mode, both units share the same virtual MAC addresses — switches don't need to update their ARP tables on failover. In A-A mode, load is shared across both units; both are actively forwarding. A-P is simpler and covers most enterprise HA requirements.

Key takeaways
  • Active-Passive = primary forwards, secondary is hot-standby (~1 second failover); Active-Active = both forward sessions but only certain traffic types load-balance — the rest stays on the primary.
  • HA cluster members must match: same model, same firmware, same FortiOS version, same number of interfaces. The exam tests this prerequisite as a gotcha.
  • Dedicated heartbeat ports (default ha1 + ha2) carry the cluster state — never expose them to the production network. Loss of all heartbeats = split-brain risk.
⚡ Mini-quiz — Drill A-P vs A-A trade-offs, cluster prerequisites, heartbeat isolation, and split-brain prevention.
Quick quiz →
Start practicing →