Fortinet · security

Fortinet NSE4 FortiGate Security

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

10Modules
30 hoursDuration
intermediateLevel
⚡ Practice the exam ← All courses

Course Modules

🔨
Module 1
FortiGate Introduction & System Setup
2 lessons
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.
🛡️
Module 2
Firewall Policies
3 lessons
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.
🔄
Module 3
Network Address Translation
2 lessons
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.
👤
Module 4
Firewall Authentication
2 lessons
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.
🔐
Module 5
SSL VPN
2 lessons
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.
🔒
Module 6
IPsec VPN
3 lessons
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.
🛡
Module 7
Security Profiles
3 lessons
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.
🔎
Module 8
SSL Inspection
2 lessons
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.
📊
Module 9
Logging & Monitoring
2 lessons
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.
⚖️
Module 10
High Availability
2 lessons
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.
Start practicing →