Free Fortinet NSE 4 Exam Flashcards

NAT mode is the default operation mode where the FortiGate routes traffic between Layer 3 interfaces with their own IP addresses and can perform NAT. Transparent mode inserts the FortiGate as a Layer 2 bridge into an existing network without changing the IP scheme, so it filters traffic without acting as a router.

FortiOS is the operating system that runs on every FortiGate. The NSE 4 exam (NSE4_FGT-7.6) is built around FortiOS 7.6. It provides the firewall engine, security profiles, VPN, routing, and the management GUI/CLI.

The web GUI (HTTPS, default port 443) is best for everyday configuration and visual monitoring. The CLI (SSH on port 22, or console) exposes commands and diagnostics that the GUI does not, and is essential for troubleshooting. The exam tests both interfaces.

VDOMs split one physical FortiGate into multiple independent virtual firewalls, each with its own policies, routing table, and administrators. Multi-VDOM mode gives fully separate instances; split-task VDOM mode keeps a mostly single-firewall device with limited segmentation.

When VDOMs are enabled, the root VDOM is created automatically and cannot be deleted. It is the default management VDOM and is commonly used for inter-VDOM routing and global services.

In the CLI, 'config global' applies settings to the whole device across all VDOMs (admin accounts, firmware, HA, interfaces). 'config vdom' then 'edit <name>' enters a specific VDOM to configure its policies and routing.

FortiGate evaluates firewall policies from top to bottom and applies the FIRST policy whose source, destination, service, and other criteria match the traffic. Subsequent policies are not checked. Policy order is therefore critical — a broad policy placed too high can shadow more specific ones below it.

At the bottom of every policy list is an implicit deny rule that blocks any traffic not matching an explicit ACCEPT policy. This 'deny by default' design means traffic must be explicitly permitted to pass.

Firewall policies reference reusable objects instead of raw values: address objects (subnet, IP range, FQDN, geography), service objects (protocol/port definitions), and schedules (time windows). This keeps policies readable and lets one change update many policies at once.

ACCEPT allows matching traffic and lets you attach NAT and security profiles. DENY silently drops the traffic with no reply to the sender. A DENY policy can still log traffic if logging is enabled, which is useful for visibility.

Each firewall policy has a permanent Policy ID assigned at creation that never changes. The sequence (row) position determines matching order and can be reordered freely. Do not confuse the ID with the evaluation order — traffic is matched by row position, not by ID value.

SNAT rewrites the source IP, typically translating private internal addresses to a public address for outbound internet access. DNAT rewrites the destination IP, typically forwarding inbound traffic from a public address to an internal server. They solve opposite directions of translation.

A VIP is a Destination NAT object that maps an external IP (and optionally port) to an internal server's IP and port. It is used in a firewall policy to publish internal services — for example, port-forwarding TCP 443 from a public IP to a web server.

An IP Pool defines one or more public addresses used as the translated source for SNAT, instead of using the egress interface IP. Pool types include Overload (PAT/many-to-one), One-to-One, and Fixed Port Range, each controlling how internal sessions map to public addresses.

With policy-based NAT, the NAT setting lives inside each firewall policy. Central NAT decouples NAT into a separate Central SNAT table and DNAT/VIP rules, evaluated independently of firewall policies. Central NAT scales better when many policies share translation rules, but the mode is device-wide.

Internal hosts use private RFC 1918 addresses that are not routable on the internet. The outbound firewall policy enables NAT so the source is translated to a public address (interface IP or IP pool); without it, return traffic could never reach the internal host.

Flow-based inspection scans packets as they stream through with minimal buffering — faster, lower latency, fewer features. Proxy-based inspection buffers and reassembles the full content before scanning — deeper inspection (e.g., better antivirus, replacement messages) at the cost of latency and memory.

Security profiles (antivirus, web filter, application control, IPS, DNS filter, file filter, etc.) are not standalone — they are attached to an ACCEPT firewall policy. Traffic must first match an allow policy, then the attached profiles inspect it.

Certificate inspection only examines the certificate and SNI/hostname of an HTTPS session — it can apply web filtering by URL category but cannot see the payload. Full (deep) SSL inspection decrypts, scans, and re-encrypts the traffic, enabling antivirus and IPS on encrypted content but requiring the FortiGate CA certificate on clients.

In full SSL inspection the FortiGate acts as a man-in-the-middle, presenting certificates it signs itself. Unless the FortiGate's CA certificate is installed and trusted on client devices, browsers show certificate warnings. Deploying the CA cert (e.g., via Group Policy) removes the warnings.

Some traffic should not be decrypted — banking, healthcare, and software that uses certificate pinning will break under full inspection. FortiGate lets you exempt sites by FortiGuard category or address, so that traffic uses certificate inspection or bypasses decryption.

Web filtering classifies websites into FortiGuard categories (e.g., Gambling, Social Networking, Malicious Websites) and lets you Allow, Block, Monitor, or Warn each category. The FortiGate queries FortiGuard servers to rate URLs that are not cached locally.

A rating override manually reassigns a specific URL to a different FortiGuard category (or a custom one). Use it when FortiGuard's automatic rating of a site is wrong or when local policy needs a site treated differently than its default category.

The static URL filter matches specific URLs/wildcards/regex you define and is checked before the FortiGuard category filter. Category filtering relies on FortiGuard's automatic classification. Use static entries for explicit allow/block exceptions; use categories for broad policy.

Application Control identifies applications by their traffic signatures and behavior regardless of port or protocol, so it can detect apps that hide on port 443. Actions include Allow, Monitor, Block, and traffic shaping (throttling), letting you control apps like streaming or P2P even when ports are not predictable.

FortiGate antivirus scans files in traffic against FortiGuard malware signatures and can also use grayware and heuristic detection. Suspicious unknown files can be forwarded to FortiSandbox for behavioral analysis to catch zero-day threats that signatures miss.

IPS inspects traffic against signatures of known exploits, scans, and attack patterns. Each signature in an IPS sensor can be set to Pass, Monitor, Block, Reset, or Quarantine. IPS protects against network attacks that target vulnerabilities, complementing antivirus which targets malware in files.

Pass allows matching traffic and does not log it. Monitor allows the traffic but generates a log so you can observe without disrupting. Block (or Reset/Drop) actually stops the attack traffic. Monitor is useful for tuning a sensor before enforcing Block.

Antivirus, IPS, web filtering, and application control depend on FortiGuard subscription services for up-to-date signatures and ratings. An expired license stops signature updates, leaving the FortiGate blind to new threats even though the features still appear configured.

Web mode gives clientless access through a browser portal with bookmarks to internal web/RDP/SSH resources — no software install. Tunnel mode uses FortiClient (or the standalone tunnel client) to assign the user an IP and route full network traffic, behaving like a true network connection.

An SSL VPN portal defines what a connecting user sees and can do: web/tunnel mode availability, split-tunneling, and bookmarks. Bookmarks are predefined links to internal resources users click within the web portal without needing to know internal addresses.

Phase 1 (IKE) authenticates the peers and builds a secure management channel — it negotiates encryption, DH group, authentication (pre-shared key or certificate), and peer identity. Phase 2 then negotiates the IPsec Security Associations that actually protect user data traffic, including the selectors and PFS.

Main Mode completes IKE Phase 1 in six messages and encrypts peer identities, making it more secure. Aggressive Mode uses only three messages and is faster but exposes identity information in clear text. Aggressive Mode is typically used with dial-up VPNs where the peer IP is unknown.

Tunnel mode encapsulates the entire original IP packet inside a new IP header — standard for site-to-site VPNs across the internet. Transport mode protects only the payload and keeps the original header, used mainly for host-to-host communication. FortiGate site-to-site VPNs use tunnel mode.

DPD sends periodic keepalive probes across an IPsec tunnel to detect when the remote peer becomes unreachable. When a peer is declared dead, the FortiGate tears down the stale SA, allowing renegotiation or failover to a backup tunnel.

With split tunneling, only traffic destined for corporate networks goes through the VPN while internet-bound traffic exits directly from the client. It reduces load on the VPN gateway and improves user experience, but means that traffic is not inspected by the FortiGate.

Local authentication stores user accounts and passwords in the FortiGate's own user database. It is simple and works without external infrastructure, but does not scale well and is not centrally managed — suited for small deployments or service accounts.

LDAP authenticates users against a directory such as Active Directory and is also used for group membership lookups; FortiGate supports LDAPS (port 636) and STARTTLS for security. RADIUS centralizes authentication, authorization, and accounting and is common for VPN and 802.1X, returning attributes that can map users to groups.

Active authentication prompts the user for credentials (a captive portal or login page) when traffic hits a policy requiring authentication. Passive authentication identifies users transparently without a prompt — FSSO is the classic example, learning identity from domain controller events.

FSSO transparently identifies users by their Active Directory logon, so identity-based firewall policies apply without an extra login prompt. The FortiGate maps the user's IP to their AD account and group membership, enabling per-user and per-group policy enforcement.

In agent-based FSSO, the Collector Agent gathers user logon/logoff events and forwards them to the FortiGate (default TCP 8000). The optional DC Agent installs on each domain controller to capture logon events directly. Polling mode instead queries the DC security event log without a DC Agent.

A static route is a manually configured path to a destination network. Administrative distance (AD) ranks route trustworthiness when multiple sources offer the same prefix — lower is preferred. On FortiGate connected routes have AD 0 and static routes default to AD 10.

Administrative distance picks which routing source wins for a prefix. When two routes have the same prefix AND the same AD, FortiGate uses route priority as the tie-breaker — the lower priority value is preferred and installed; the other becomes a backup. A higher-AD static route is used only when the primary fails.

PBR routes traffic based on criteria beyond the destination IP — such as source address, incoming interface, protocol, or port. PBR rules are evaluated before the regular routing table, letting you, for example, send specific traffic out a different ISP link.

OSPF is a link-state interior protocol that builds a full topology map within an autonomous system and converges quickly. BGP is the path-vector protocol of the internet, exchanging routes between autonomous systems. FortiGate supports both for scalable, automatically updated routing.

FGCP is the protocol FortiGates use to form a high-availability cluster. It synchronizes configuration, elects the primary unit, and exchanges heartbeats so a standby unit can take over if the primary fails. Heartbeat interfaces carry this control traffic.

In Active-Passive HA, one primary unit processes all traffic while the others stay synchronized and idle until failover. In Active-Active HA, the primary also load-balances proxy-based inspection sessions to secondary units, using their resources while still providing redundancy.

HA override forces the highest-priority unit to become (or reclaim) primary after recovery; without it, the current primary stays primary to avoid disruption. Session pickup synchronizes the session table so existing connections survive a failover instead of being dropped.

FortiGate can log to local disk, memory, syslog servers, FortiAnalyzer, FortiCloud, or FortiGate Cloud. Each log type (traffic, security, event) has a severity level. FortiGate sends logs to FortiAnalyzer over the reliable, compressed OFTP protocol for centralized analysis and reporting.

The Security Fabric links Fortinet products — FortiGate, FortiAnalyzer, FortiManager, FortiSwitch, FortiAP, FortiClient EMS, and more — into one coordinated system that shares telemetry and threat intelligence. A root FortiGate anchors the fabric, enabling end-to-end visibility, topology views, and automated threat response.