FortiGate Firewall Interview Questions & Answers

A brand-new FortiGate gives you several front doors, and a good admin picks based on the situation:

• Web GUI (HTTPS) — connect a laptop to the management port (usually port1 or a dedicated mgmt port), browse to the default IP, and you get a friendly graphical wizard. Best for first-time setup and day-to-day work.
• CLI via SSH — same management IP, but text commands. Faster for bulk changes and scripting.
• Console cable (serial) — a physical RJ-45-to-serial or USB cable. This is your lifeline if you ever lose the IP, lock yourself out, or need to recover the box. It always works even with no network.
• FortiManager — central management for many FortiGates at once.

Think of the console port as the spare key under the doormat — slow, but it never fails.

Interview tip: Always mention console access as the guaranteed recovery path when network access fails.

Out of the box, most FortiGate models put the management interface on port1 (or a dedicated mgmt port on larger units) with the default IP 192.168.1.99/24. So you set your laptop to something like 192.168.1.100/24 with gateway 192.168.1.99, plug into that port, and browse to https://192.168.1.99.

• The default login is username admin with a blank (empty) password.
• FortiOS immediately forces you to set a strong password on first login — and you should, because a firewall with no admin password is a wide-open door.

Always verify the exact default IP and port in the QuickStart guide for your specific model, since a few models differ.

Interview tip: State the trio clearly — 192.168.1.99, user admin, empty password — and stress that changing the password is mandatory on first login.

The first-touch checklist on any new FortiGate:

1. Set a strong admin password (the default is blank).
2. Set the hostname so you can identify the box in logs and central management.
3. Set the correct timezone and prefer NTP (config system ntp) so the clock auto-syncs instead of drifting.
4. Then configure interfaces, default route, DNS, and register the unit.

Accurate time is surprisingly critical. Logs use timestamps — if the clock is wrong, your timeline during an incident investigation is useless. Digital certificates have valid-from/valid-to dates, so a wrong clock can make a perfectly good cert look expired (or not-yet-valid), breaking HTTPS inspection and admin access. IPsec VPNs and authentication tokens are also time-sensitive.

Think of NTP as everyone agreeing on the same wall clock before a meeting.

Interview tip: Tie wrong time directly to three failures — broken log correlation, false cert expiry, and VPN/SAML auth failures.

FortiOS ships with Daylight Saving Time turned on. You disable it from the CLI under the global time settings:

• config system global
• set dst disable
• end

You would turn DST off when your region does not observe it (for example, most of India stays on IST year-round with no clock change). If DST is left on in a non-DST region, FortiOS will shift the clock by an hour twice a year, which silently throws your log timestamps off by 60 minutes during incident analysis and can desync correlation with other devices.

It is a small setting, but in a forensic investigation a one-hour skew can completely break your event timeline.

Interview tip: The reason interviewers like this question is the consequence — disabling DST in a non-DST region keeps your logs and cross-device timelines accurate.

A FortiGate runs in one of two operation modes:

• NAT/Routing mode (the default) — the FortiGate acts like a Layer 3 router. Each interface has its own IP, it routes between subnets, and it can perform NAT. This is how most edge/gateway firewalls are deployed.
• Transparent mode — the FortiGate behaves like a Layer 2 bump-in-the-wire (a smart bridge). Interfaces have no routing IPs; you only assign one management IP for admin access. Traffic passes through invisibly while still being inspected.

You choose Transparent mode when there is already a router or firewall doing the routing and NAT, and you simply want to drop the FortiGate inline to add IPS/antivirus/web filtering without re-IPing the network. Because it is invisible at Layer 3, you avoid changing gateways, subnets, or routing.

One note for modern FortiOS: operation mode is now usually set per-VDOM rather than globally, so one box can run some VDOMs in NAT mode and others in Transparent mode.

Think of Transparent mode as a security checkpoint added mid-hallway — everyone keeps walking the same path, but now they get screened.

Interview tip: Key phrase — Transparent mode adds UTM inline with zero IP/topology changes, and mode is selected per-VDOM in current FortiOS.

To get a NAT-mode FortiGate online, you wire up the minimum routing and policy pieces:

1. WAN interface — give the Internet-facing port an IP (static from your ISP, or DHCP/PPPoE if the ISP assigns it).
2. LAN interface — give the internal port an IP that becomes the gateway for your users.
3. Default static route — 0.0.0.0/0 pointing out the WAN interface with the next-hop set to the ISP gateway IP. This tells the FortiGate where to send any traffic it doesn't have a more specific route for. (With DHCP/PPPoE the gateway is learned automatically.)
4. DNS servers so names resolve.
5. A firewall policy from LAN to WAN with NAT enabled so private IPs are translated to the WAN IP.

The default route is like a post office's catch-all bin — anything without a known destination goes to the ISP.

Interview tip: Don't forget the NAT-enabled LAN-to-WAN policy — interfaces and a route alone won't pass user traffic.

Registering the FortiGate (by its serial number on the Fortinet support portal, or via the GUI) links the device to your account and any FortiCare/FortiGuard subscriptions you bought. This unlocks the value of the box:

• Firmware downloads and the ability to open support (TAC) tickets.
• FortiGuard security services — the live threat-intelligence feeds the firewall needs to actually block modern threats: Antivirus signatures, IPS signatures, Web Filtering / URL categories, Application Control, Anti-Spam, DNS Filter, and IoT/device detection.
• Without registration and a valid license, those FortiGuard databases stop updating and the firewall slowly goes blind to new attacks.

Think of it like a car: you can drive it, but without the service subscription you stop getting safety recalls and map updates.

Interview tip: Registration unlocks firmware + TAC support, but licensed FortiGuard subscriptions are what keep AV/IPS/Web-Filter signatures current.

The golden rule: always back up the running config first, and confirm you can roll back. Your backup targets:

• GUI — System > Configuration > Backup, saved to your PC (optionally encrypted with a password).
• CLI — execute backup config to TFTP, FTP, or USB; for example execute backup config usb or execute backup config tftp.
• USB drive plugged into the unit.
• FortiManager, which keeps centralized config revisions for the whole fleet.

Rollback options: restore the saved config file, use FortiManager's revision history, or — if an upgrade goes badly — boot the backup firmware partition or TFTP-load a known-good image from the BIOS boot menu. Also read the firmware upgrade path notes, because skipping versions can corrupt config (FortiOS will not always migrate settings across skipped releases — the SSL-VPN-to-IPsec change in 7.6.3 is a real example).

Think of it as saving your game before the boss fight.

Interview tip: Mention encrypted backup + checking the official upgrade path — both are real-world differentiators.

A packet's journey through FortiOS follows a fixed order. For the first packet of a new session:

1. Ingress on the interface.
2. DoS policy and IP integrity / header checks — malformed or flood traffic is dropped early.
3. IPsec decryption (if the packet arrived in a tunnel).
4. Destination NAT (DNAT / VIP) — done before the route lookup, so the kernel routes toward the real (translated) destination.
5. Routing — pick the egress interface.
6. Policy lookup — the firewall policy table is evaluated top-down, first-match (allow/deny); this is where the session is created in the session table.
7. Source NAT on egress.
8. UTM / security inspection (IPS, AV, web/app filter, SSL inspection) via the flow or proxy engine.
9. Egress out the interface.

Order matters because each stage can silently drop the packet. Because DNAT runs before the route lookup, your policy and route must reference the translated address, not the original. When troubleshooting with diagnose debug flow, you watch exactly where the packet dies — at the route, at the policy, or in UTM — and that tells you precisely which config to fix.

Interview tip: Stress that DNAT happens before routing/policy and SNAT after — and that diagnose debug flow prints the stages in order so you can pinpoint the drop.

The branding here has gone back and forth, so know the timeline. Fortinet originally used the NSE ladder (NSE1–NSE8); the engineer-level FortiGate exam was NSE 4. Around 2023 Fortinet rebranded into Fortinet Certified tiers — Associate (FCA), Professional (FCP), Solution Specialist (FCSS), Expert (FCX) — and NSE 4 became the FCP – FortiGate Administrator exam.

• In 2025 Fortinet reverted the FortiGate Administrator exam name back to NSE 4: effective 15 October 2025 the FCP – FortiGate 7.6 Administrator exam was renamed NSE 4 – FortiOS 7.6 Administrator (exam code NSE4_FGT_AD-7.6); the old FCP-named 7.6 exam was retired at the end of 2025. The 7.4 exam still carries the FCP code FCP_FGT_AD-7.4. The topics and difficulty did not change — only the name.
• So today's current FortiGate Administrator exam is NSE 4 – FortiOS 7.6 Administrator, while the broader FCP certification tier (earned by passing two FCP-level exams) still exists.

Exam domains cover core FortiGate administration: deployment and initial setup, firewall policies and NAT, authentication, the SSL and IPsec VPNs, security profiles/UTM (AV, web filter, IPS, application control), routing, SD-WAN, high availability (HA), and logging/monitoring with the FortiOS Security Fabric.

Think of it as the same engineer-level knowledge whose label flip-flopped — NSE 4, then FCP, now NSE 4 again on FortiOS 7.6.

Interview tip: Say plainly: "The FortiGate Admin exam was NSE 4, was branded FCP–FortiGate around 2023, and the 7.6 exam was renamed back to NSE 4 (NSE4_FGT_AD-7.6) in October 2025 — the 7.4 exam still uses the FCP code." That precision shows you're current.

An untagged (access) port belongs to exactly one VLAN; frames carry no VLAN tag, so it connects to a single end device or a switch access port. A tagged 802.1Q port carries many VLANs over one wire by adding a 4-byte VLAN tag to each frame — this is a trunk. Think of the trunk as a multi-lane highway and each VLAN tag as the lane number.

To route between VLANs over one physical link (router-on-a-stick), you create VLAN sub-interfaces. In the GUI go to Network > Interfaces > Create New > Interface, set Type to VLAN, pick the physical parent port, give a VLAN ID, and assign an IP. Each sub-interface becomes its own routed gateway, and firewall policies between them control the inter-VLAN traffic.

Interview tip: a VLAN sub-interface inherits the same VDOM as its parent port, and the upstream switch port must be a matching 802.1Q trunk carrying those VLAN IDs.

A zone is a logical grouping of one or more interfaces (or VLAN sub-interfaces) that you reference in a firewall policy as a single object. Instead of writing separate rules for port2, port3 and port4, you put them in a zone like INTERNAL and write one policy. Think of a zone as a folder that holds several interfaces.

The intra-zone setting controls traffic between interfaces inside the same zone. With set intrazone allow, members can talk to each other without any policy. With set intrazone deny (the default on modern FortiOS), traffic between members is blocked unless you write an explicit same-zone policy — useful when you want to inspect or restrict even hosts in the same zone.

Grouping cuts the policy count, reduces mistakes, and keeps the table readable as you add ports.

Interview tip: an interface can belong to only one zone, and once it is zoned you reference the zone (not the member interface) in policies.

Aggregate (LACP/802.3ad) bonds several physical ports into one logical link that adds bandwidth and survives a single link failure; the partner switch must also run LACP (or be in a static LAG). Pick it for high-throughput uplinks to one switch or a stacked/MLAG pair.

Redundant interface also bundles ports but only one is active at a time — the others stand by for failover. There is no bandwidth gain and no LACP needed on the peer; pick it for pure resilience, including splitting links across two separate switches.

Software switch merges multiple ports into one Layer-2 bridge/broadcast domain in software (CPU-handled, so slower), so hosts on different ports share one subnet. Good for small LANs or wired-plus-WiFi convergence.

Hardware switch does the same Layer-2 merge but in the device's switch ASIC/NP fabric, so it is line-rate. Pick it on platforms with a built-in switch fabric for fast LAN switching.

Interview tip: aggregate = bandwidth + redundancy; redundant = redundancy only; software switch = CPU-based bridge; hardware switch = ASIC-based bridge.

FortiGate first checks policy routes (PBR), then the routing table (FIB). Policy routes win because they let you steer traffic by attributes the routing table ignores — source address, incoming interface, protocol or port — overriding normal destination-based routing. Think of PBR as an express lane checked before the regular map.

If no policy route matches (or the matched policy route's egress is down), the FIB is used. Route selection there is: longest prefix match first; among equal prefixes the lowest administrative distance decides which route is installed in the FIB; among routes already installed in the FIB, lower priority is preferred; routes with equal distance and equal priority form ECMP (load sharing). Connected routes have distance 0, the default static route distance is 10, then dynamic (eBGP 20, OSPF 110, iBGP 200).

Confirm with diagnose firewall proute list for PBR, get router info routing-table all for the FIB, and diagnose debug flow to watch the live forwarding decision.

Interview tip: administrative distance picks which route enters the FIB; priority chooses among routes already in it.

Administrative distance (AD) decides whether a route is trustworthy enough to be installed in the routing table (FIB). Among routes to the same prefix, only the one with the lowest AD is installed. Priority only matters among routes already installed in the FIB with the same AD; the lower-priority route is preferred for forwarding.

Primary/backup default route: give the primary ISP a default route with AD 10 and the backup a higher AD (e.g. 20). Only the primary sits in the FIB; if its gateway/link dies (link-monitor or dead-gateway detection removes it), the AD-20 route installs and traffic fails over. Alternatively, keep the same AD but a higher priority number on the backup — both stay visible, and the lower-priority (primary) path is used while it is up.

ECMP: configure two default routes with identical AD and identical priority; both install and the FortiGate load-shares across them per the ECMP algorithm (source-IP, source-dest, or weighted).

Interview tip: different AD = clean failover (only one route in the FIB); equal AD + equal priority = ECMP.

RPF is FortiGate's built-in anti-spoofing check. For every new session, the firewall looks at the packet's source IP and asks: would my routing table send a reply back out the same interface the packet arrived on? If not, the packet is treated as spoofed and dropped. Think of it as a bouncer checking that you came in through your own door.

Strict RPF requires the best/active route to that source to point back out the receiving interface — tight, but it can drop legitimate traffic in asymmetric-routing designs. Loose (feasible) RPF only requires that any route to the source exists in the FIB (regardless of interface), so it tolerates asymmetric paths while still blocking truly unroutable sources. On FortiGate, loose mode is the default.

In diagnose debug flow you would see a message like "reverse path check fail, drop". You set the mode per VDOM with config system settings then set strict-src-check enable (or disable for loose).

Interview tip: asymmetric routing breaking traffic with a reverse-path-check drop usually means you are in strict mode — switch to loose RPF.

A blackhole route is a static route whose interface is set to a special discard pseudo-interface (Blackhole) instead of a real next hop. Any packet matching that prefix is silently dropped — the traffic disappears into a black hole. It is configured in the GUI/CLI as a static route with the destination prefix and the blackhole interface.

Common uses: (1) drop traffic to known-bad or unused prefixes cheaply, without burning a firewall policy or generating ICMP unreachables; (2) install a summary blackhole for your VPN/internal supernet at a higher administrative distance so that when a more specific IPsec/dynamic route is up it is preferred, but if the tunnel drops, traffic hits the blackhole instead of following the default route back out to the Internet (a security and routing-loop safeguard).

Think of it as a recycling bin for packets you never want forwarded.

Interview tip: a backup blackhole prevents VPN traffic from leaking to the Internet when the tunnel goes down.

OSPF is a link-state IGP. Routers are grouped into areas that all connect to the backbone area 0; areas limit flooding and let you summarize. Routers describe their links in LSAs (Type 1 router, Type 2 network, Type 3 inter-area summary, Type 5 external) that build a shared topology database, then each router runs SPF to compute routes.

Adjacency progresses through Down to Init to 2-WAY to ExStart to Exchange to Loading to Full. 2-WAY is normal between two DROTHERs on a broadcast segment (they intentionally do not go Full with each other, only with the DR/BDR).

Stuck at ExStart: almost always an MTU mismatch between the two interfaces, or a duplicate router-ID issue. Stuck at 2-WAY (unexpected): check DR election priorities and the OSPF network type.

On FortiGate verify with get router info ospf neighbor, get router info ospf interface, matching area, hello/dead timers, authentication, subnet mask, MTU, and diagnose ip router ospf level info for detail.

Interview tip: ExStart stuck almost always equals MTU mismatch — check it first.

BGP is the path-vector protocol used between sites and ISPs. eBGP peers sit in different autonomous systems (AS), are usually directly connected, and have an administrative distance of 20; iBGP peers are in the same AS, often multi-hop, AD 200, and require a full mesh or route reflectors to avoid loops.

Key attributes you tune for traffic engineering: Weight (Fortinet/Cisco-style, local to the one router, highest wins), Local Preference (AS-wide, highest wins, controls outbound path), AS-Path prepend (lengthen the path to make it less attractive inbound), MED (hint to a neighbor AS, lowest wins), and communities for tagging.

On FortiGate, prefix-lists match which networks, route-maps then permit/deny or set attributes (local-pref, prepend, community), and you attach them as inbound/outbound route-map / distribute-list filters per neighbor to control exactly what is advertised and accepted.

Think of route-maps as if-then rules: "if prefix matches list X, then set this attribute."

Interview tip: Local Preference steers outbound (it is AS-wide); AS-Path prepend influences inbound.

A one-arm sniffer turns a FortiGate interface into a passive monitor. You connect it to a switch SPAN/mirror port (or a network TAP), and the FortiGate inspects a copy of the traffic with IPS, application control and antivirus engines — but it is out of the data path, so it can detect and log/alert but cannot block or modify live traffic. Think of it as a CCTV camera watching the road, not a toll gate on it.

Inline deployment places the FortiGate directly in the traffic path (NAT/route or transparent mode), so every packet must pass through it. There it can actively allow, drop, reset or shape traffic in real time — full prevention.

Use a sniffer for low-risk evaluation, proof-of-value, or monitoring without touching the network; use inline for actual enforcement.

Interview tip: sniffer = detection-only (IDS-style, no blocking); inline = full prevention (IPS-style). It is configured by setting the interface role to sniffer / one-arm mode.

To verify the chosen route, start with the routing table (RIB): get router info routing-table all shows the full table, and get router info routing-table 203.0.113.0 narrows to a destination. get router info routing-table details 203.0.113.0 adds detail such as multiple next-hops, metrics/distance, and which protocol installed the route.

For ECMP (equal-cost multipath) you will see several next-hops for the same prefix; the FortiGate load-balances across them per its configured ECMP method (source IP, source-destination, or weighted), so the exact path a flow takes depends on the hash.

Crucially, policy routes are evaluated before the routing-table lookup. Check them with get router info policy-routing (or diagnose firewall proute list); a matching policy route overrides the normal route lookup. The definitive per-flow answer comes from diagnose debug flow, which prints the route actually used for that packet.

Interview tip: Always check policy routes too; they silently override the routing table.

FortiGate evaluates firewall policies top-down, first-match-wins. The first policy whose criteria all match the packet (incoming/outgoing interface, source/destination address, service/port, schedule, and any user/group requirement) is applied, and the search stops there. Think of a security guard reading a checklist top to bottom and acting on the first line that fits.

The policy ID is just a permanent label assigned when the policy is created; it never changes when you reorder policies and has no effect on matching priority. The sequence (the row order) is what actually decides which policy wins, so a low-ID policy can sit below a high-ID one. Always place specific policies above broad ones, or the broad rule will shadow the specific one.

If no policy matches, traffic hits the built-in implicit deny (policy 0), which drops it. By default this drop is not logged; in modern FortiOS you can turn on logging for the implicit deny so you can see denied traffic during troubleshooting.

Interview tip: Stress that row order, not the ID number, controls matching.

A FortiGate firewall policy is built from clear blocks: incoming and outgoing interface (where traffic enters and leaves), source and destination address objects (the who and where), service (the protocol/port, for example HTTPS), and schedule (when it is allowed, for example business hours). The action is ACCEPT or DENY. If ACCEPT, you can enable NAT (source NAT, optionally via an IP pool), turn on logging (all sessions or security events only), and attach security profiles (antivirus, web filter, IPS, application control, plus an SSL/SSH inspection profile) for deep inspection.

It is like a doorman rule: who, to where, for what, when, and whether they get inspected.

The CLI command set status disable (the Enable/Disable toggle in the GUI) turns a policy off without deleting it, so the rule is skipped during matching but kept for later re-enabling.

Interview tip: Name the blocks in order; it shows you understand the matching flow.

The GUI shows firewall policies two ways. Interface Pair View groups policies into sections by their incoming/outgoing interface pair (for example LAN to WAN). It is tidy and easy to read, but it can hide the true global order because each section is shown separately.

By Sequence View lists every policy in one flat list in the exact top-down order the FortiGate evaluates them. Since matching is first-match-wins across the whole table, this is the view that reflects what the firewall actually does.

For troubleshooting, By Sequence matters because a broad early policy can shadow a specific later one even when they sit in different interface-pair sections. Interface Pair View can fool you into thinking a rule is reachable when an earlier rule grabs the traffic first.

Interview tip: Say you switch to By Sequence View to spot shadowed or out-of-order policies.

A VIP (Virtual IP) does Destination NAT (DNAT). It maps an external/public address (and optionally a port) to an internal server. It applies to inbound traffic: outsiders connect to the public IP and the FortiGate rewrites the destination to the real internal IP. This is classic port forwarding.

An IP Pool does Source NAT (SNAT). It defines the address (or addresses) the FortiGate uses to rewrite the source of outbound traffic, instead of the egress interface IP. This is useful when you need many public source IPs or a specific, stable source IP.

In the default per-policy NAT model, a policy must list the VIP as its destination because the VIP object both defines the public-to-internal mapping and tells the policy engine which public destination this rule covers. FortiGate matches the policy against the VIP reference, then performs the DNAT. Putting the real internal IP in the policy would never match the inbound packet, which still carries the public destination address.

Interview tip: VIP = inbound/destination NAT, IP Pool = outbound/source NAT.

With per-policy NAT (the default), NAT is configured inside each firewall policy: you toggle NAT on, optionally pick an IP pool for SNAT, and the NAT decision is tied to whichever policy the traffic matched. Inbound DNAT uses a VIP that is referenced as the policy destination.

Central NAT separates NAT from the security policies. Source NAT lives in a dedicated Central SNAT table and destination NAT in the DNAT & Virtual IPs table, each evaluated as its own ordered, top-down list independent of the firewall policy. A key behavior change: with Central NAT you no longer put the VIP in the policy as the destination; DNAT is applied first by the DNAT table, and the firewall policy then matches on the real (translated) internal address.

Choose Central NAT for large or complex environments where you want one consistent NAT table, granular SNAT control, or to avoid duplicating NAT settings across many policies. Ordering difference: per-policy NAT applies after the matching policy is chosen, whereas Central NAT evaluates DNAT before the policy and consults the separate Central SNAT list for outbound translation. Central NAT is a per-VDOM mode toggle that changes how VIPs and SNAT are configured.

Interview tip: Central NAT is a global/per-VDOM toggle and changes how VIPs are referenced in policies.

FortiGate IP pool types control how source NAT is done:

• Overload: many internal hosts share one (or a few) pool IPs using PAT (port translation). Most common; maximises address reuse.
• One-to-One: each internal IP maps to a dedicated pool IP with no port translation; needed when an application or remote peer requires a stable, unique source IP.
• Fixed Port Range: maps an internal IP range to an external IP range while preserving the original source port (no port translation); useful for protocols that break when the source port is rewritten.
• Port Block Allocation (PBA): assigns each internal host a contiguous block of ports on a shared public IP, and logs at block granularity.

You need PBA for carrier-grade NAT and scalable logging: one log entry per allocated block instead of per session, which makes audit and lawful-intercept traceability practical at very high session counts. Use fixed-port-range when an application must keep its original source port or you need a deterministic internal-to-external mapping.

Interview tip: PBA exists mainly to make NAT logging scalable.

Hairpin NAT (NAT loopback) is needed when an internal user reaches an internal server using its public VIP address instead of the private IP. The request is sent to the firewall toward the public IP, but the server sits on the same internal side, so without special handling the reply path is asymmetric: the server would answer the client directly with its private IP, the client never sees a reply from the public IP it contacted, and the connection fails. The packet must do a U-turn (hairpin) on the FortiGate.

To configure it: create the VIP as usual (public IP to internal server), then build a firewall policy where both the incoming and outgoing interface are the internal/LAN interface, source is the internal subnet, destination is the VIP object, and crucially enable NAT (source NAT). The SNAT makes the server see the firewall as the source, so the reply returns through the FortiGate and the path stays symmetric.

Analogy: posting a letter to your own house but addressing it to the public post-office box.

Interview tip: Stress that you MUST enable source NAT on the hairpin policy.

In the FortiGate packet flow, the DNAT translation for a VIP happens early, before the route lookup that selects the egress interface and before the firewall policy is applied. The kernel checks the destination against configured VIPs and rewrites it to the real internal IP, so routing then chooses the egress interface based on the translated (internal) address.

The subtle part is what you write in the policy, and it depends on the NAT model. In the default per-policy NAT model, even though the destination is translated early, the firewall policy is still written and matched using the VIP object (the original public address) as its destination, because the policy engine evaluates against the VIP reference rather than the post-translation IP. If you instead put the real internal IP as the policy destination, the rule will not match and the traffic is denied. (Under Central NAT the opposite is true: DNAT is handled by the separate DNAT table and the policy matches on the real internal IP.)

Analogy: the mailroom relabels the envelope to the internal desk, but the routing rule is still filed under the public PO-box name.

Interview tip: DNAT before routing/policy; with per-policy NAT the policy still references the VIP object.

A basic port-forward VIP maps one public IP/port to a single internal server, one-to-one. A server load-balancing (virtual-server) VIP instead distributes incoming connections across a pool of real servers, giving you redundancy and scale, like a receptionist sending callers to whichever agent is free.

You enable it by setting the VIP type to server-load-balance and choosing a load-distribution method such as static (round-robin), weighted, least-session, least-RTT, or source-IP hash. FortiGate can also do basic L7 handling (HTTP/HTTPS) and SSL offload.

For health checks, configure monitors (PING, TCP connect, or HTTP/HTTPS with an expected response) so dead servers are pulled out of rotation automatically. For persistence, use source-IP affinity, HTTP cookie, or SSL session ID so a client stays on the same backend for the duration of a session.

Interview tip: Mention health checks AND persistence; both show real load-balancing understanding.

NAT64 lets IPv6-only clients reach IPv4-only servers. The FortiGate embeds the IPv4 destination inside a special IPv6 prefix (commonly the well-known 64:ff9b::/96) and works with DNS64, which synthesises an AAAA record so the client sends IPv6 that the firewall translates back to IPv4. NAT46 is the reverse: it lets IPv4 clients reach IPv6-only resources.

You need an IPv6-to-IPv4 (or IPv4-to-IPv6) translation policy whenever the two ends speak different IP versions and cannot run dual-stack, for example a modern IPv6-only network that still must reach legacy IPv4 services, or exposing an internal IPv6 service to the IPv4 internet.

On FortiGate you enable the NAT64/NAT46 feature, configure the prefix and a matching IPv6/IPv4 policy, and pair NAT64 with DNS64. Think of it as a translator between two languages that cannot otherwise converse.

Interview tip: NAT64 = IPv6 client to IPv4 server, and it needs DNS64.

FortiGate's UTM (Unified Threat Management) security profiles attach to a firewall policy so matching traffic is scanned beyond just IP and port. Think of the policy as the door and each profile as a different guard checking one specific thing.

• AntiVirus — scans files carried in traffic (HTTP, SMTP, FTP, IMAP/POP3, etc.) for malware using signatures, heuristics, and optional sandbox/AI lookups.
• IPS — inspects packet payloads against attack signatures (exploits, buffer overflows, scans) and can block inline.
• Web Filter — rates the URL/site by FortiGuard category (or a local URL list) and allows, monitors, or blocks accordingly.
• Application Control — identifies the actual application (Facebook, BitTorrent, TikTok) by signature, regardless of port.
• DNS Filter — inspects DNS queries to block malicious domains and botnet/C2 lookups before any connection is made.
• DLP (Data Loss Prevention) — detects sensitive data (PII, card numbers, watermarked files) leaving the network.
• File Filter — allows or blocks by true file type (e.g. exe, zip) detected from content, not just the file name/extension.

Interview tip: UTM profiles attach to a firewall policy, not globally — if traffic does not match a policy that references the profile, that traffic is never inspected.

Flow-based inspection examines packets as they stream through, scanning content on the fly without holding the whole object. It is fast and low-latency — like a guard glancing at items on a moving conveyor belt. Proxy-based inspection terminates the client connection, fully buffers and reassembles the object, scans the complete file, then opens a separate connection to the server to forward it — like a guard taking the whole parcel off the belt, opening it fully, then re-sending it.

Trade-off: flow-based gives higher throughput and lower latency but can be less thorough on multi-packet/reassembled content. Proxy-based gives deeper, more accurate scanning (better for AntiVirus and DLP, and it can hold a file until the verdict is known) at the cost of more memory, latency, and CPU.

Block pages: proxy-based controls the full session, so it can return a clean, customizable replacement message / block page to the user. Flow-based historically just reset or dropped the connection, so the user often saw a generic browser error — but modern FortiOS can also inject replacement-message block pages in flow mode for HTTP/HTTPS, so the gap has narrowed.

Interview tip: the inspection mode is selected on the firewall policy. Flow is the default for performance; choose proxy when you need the deepest AntiVirus/DLP accuracy or guaranteed block-and-hold behavior.

FortiGate hardware uses dedicated ASICs: the NP7 network processor offloads packet forwarding and session handling, while the CP9 content processor accelerates pattern matching and crypto (IPS engine, antivirus pattern matching, SSL/TLS). The goal is to keep traffic on the fast path rather than punting every packet to the main CPU.

Flow-based inspection is the mode that stays friendliest to acceleration: the session can remain NP7-offloaded for forwarding while IPS and flow AntiVirus lean on the CP9 for scanning. Proxy-based inspection terminates and reassembles the traffic in software (the proxy daemon), so the forwarding session itself generally cannot be NP7-offloaded and rides the slower CPU/proxy path — even though the CP9 can still help with the actual content scan and crypto.

Things that drop a session off the NP fast path or break offload include: proxy-mode profiles, asymmetric routing, heavy fragmentation, sessions needing per-packet inspection or deep payload manipulation, certain DLP/IPS scenarios, and protocol/feature combinations the NP7 does not support. Verify with diagnose sys session list (check the npu info / offload flags), and inspect NP behavior with the diagnose npu np7 family of commands.

Interview tip: say "flow-based keeps the session NP7-offloaded and uses CP9 for scanning; proxy-based terminates in software so the forwarding session leaves the NP fast path," and that you would confirm offload state with diagnose sys session list and diagnose npu np7.

Certificate inspection is lightweight: FortiGate reads only the unencrypted parts of the TLS handshake — the SNI (Server Name Indication) in the client hello and the hostname in the server certificate's CN/SAN — to learn which site is being visited. It never decrypts the payload, so it can apply Web Filtering by domain/category but is blind to what flows inside the encrypted tunnel.

Deep / full inspection is a controlled, policy-enforced man-in-the-middle: FortiGate intercepts the session, decrypts it, scans the cleartext, then re-encrypts it toward the server, presenting the client a certificate it re-signs on the fly with its own CA. It can see and act on everything inside HTTPS.

Because AntiVirus and DLP must read the actual file content or data payload — and on HTTPS that payload is encrypted — they only function if the traffic is first decrypted. Certificate inspection exposes only the hostname (SNI/CN), so AV and DLP have nothing to scan over HTTPS without deep inspection. Analogy: certificate inspection reads the envelope's address; deep inspection opens the letter — and AV/DLP need to read the letter.

Interview tip: "AntiVirus and DLP over HTTPS require deep inspection because certificate inspection only exposes the SNI/CN, not the encrypted payload they need to scan."

During deep inspection FortiGate re-signs every HTTPS site on the fly, and Fortinet_CA_SSL is the default built-in CA certificate it uses to do that re-signing. So when a user visits, say, a bank, the certificate the browser actually receives was issued in real time by Fortinet_CA_SSL, not by the site's real public CA.

The problem: browsers and operating systems only trust certificates that chain up to a CA already in their trusted root store. Fortinet_CA_SSL is not in that store by default, so the client treats every re-signed site as untrusted and shows a "your connection is not private / certificate not trusted" warning.

The fix: export the FortiGate's SSL inspection CA certificate (Fortinet_CA_SSL, or — recommended — a custom CA you generated/imported on the FortiGate) and install it as a trusted root CA on every client endpoint. At scale this is pushed via Active Directory Group Policy (GPO) or an MDM/Intune profile; standalone hosts are done manually. Browsers with their own trust store (Firefox by default, and some apps) need the CA imported separately. Best practice in production is to use your own private CA rather than the shared default Fortinet_CA_SSL.

Interview tip: always mention deploying the CA via GPO/MDM at scale — manual install does not survive an enterprise fleet.

Certificate pinning is when an app hard-codes (pins) the exact certificate or public key it expects from its server. When FortiGate does deep inspection and re-signs with its own CA, the presented certificate no longer matches the pin, so the app refuses the connection — even though you installed the FortiGate CA as trusted. Banking apps, Windows/Apple OS update services, Chrome/Firefox update channels, Dropbox, and many mobile apps pin.

How to identify it: the tell-tale symptom is an app that fails only when deep inspection is enabled and works again when you switch the policy to certificate inspection. Confirm by checking FortiGate logs and running diagnose debug flow (with a filter for the host/IP), looking for TLS handshake or connection failures to those specific hostnames.

The fix — SSL exemptions: in the SSL/SSH Inspection profile, add the affected destinations to the Exempt from SSL Inspection list. You can exempt by FortiGuard category (e.g. Finance and Banking), by specific address/FQDN objects, or use Fortinet's built-in Reputable Websites exemption. Exempted traffic is not decrypted; it falls back to certificate-level handling (visible only by SNI/CN), so the pin stays intact.

Interview tip: exempting the whole Finance and Banking category is the standard, low-risk way to stop deep inspection from breaking banking apps.

FortiGate Web Filtering combines two mechanisms. FortiGuard category filtering sends the visited domain to Fortinet's cloud rating service, which returns a category (e.g. Gambling, Social Media, Malicious Websites). You then set an action per category — Allow, Monitor, Block, Warning, or Authenticate — so you govern millions of sites through roughly 90 categories instead of one URL at a time. The static URL filter is your own manual list of specific URLs or patterns (with actions Exempt, Block, Allow, or Monitor). It is evaluated before the FortiGuard category lookup, so it is ideal for explicit exceptions.

Actions beyond Allow/Block:

• Warning — shows a warning page; the user can click to proceed (the action is logged).
• Authenticate — forces the user to authenticate before accessing that category.
• Quota — sets a daily time or bandwidth allowance per category (e.g. 30 minutes/day of social media), after which access to that category is blocked for the rest of the day.

Analogy: categories sort sites into labeled bins; a quota is a metered allowance per bin.

Interview tip: the static URL filter is evaluated first, so an Exempt or Allow entry there can override a category that is otherwise blocked — useful for whitelisting one trusted site inside a blocked category.

Web Filter acts at the HTTP/HTTPS layer, once a connection to the site is already being set up. The DNS Filter profile acts earlier, at the DNS resolution layer: it inspects the domain the moment the client tries to resolve it, before any TCP/QUIC connection to the destination is even attempted. It is like stopping someone at the phone book before they ever dial the number.

Key things DNS Filter adds: it applies FortiGuard category ratings to DNS queries, can redirect blocked lookups to a FortiGuard block portal/sinkhole IP, and crucially includes a Botnet C&C (command-and-control) domain database. Malware frequently "phones home" to a C2 server by resolving a domain first, so DNS Filter can block that lookup and cut the malware's communication even if a host is already infected.

It also helps against DNS-layer threats such as DNS tunneling, fast-flux domains, and newly-registered or typosquatted malicious domains, and it can block DoH/DoT so users cannot bypass DNS controls with encrypted resolvers.

Interview tip: stress the layer difference — DNS Filter blocks the name resolution (earlier), Web Filter blocks the page request (later) — and call out the Botnet C&C database as the standout feature.

FortiGate IPS (Intrusion Prevention System) inspects packet payloads for attacks and can block them inline. It uses two detection styles:

• Signature-based — matches traffic against FortiGuard's database of known attack patterns (a specific exploit, a CVE, malware behaviour). It is like antivirus for network attacks.
• Rate-based — triggers on abnormal volume or frequency rather than a content pattern, e.g. too many failed logins or a flood of connections in a short window — useful against brute-force and DoS-style activity.

An IPS sensor is the profile container you build by selecting groups of signatures (filtered by severity, target, OS, protocol, etc.) and assigning each an action — pass, monitor, block, reset, or quarantine — then you attach the sensor to a firewall policy. You tune the sensor to your environment rather than blindly enabling every signature.

You write a custom signature when FortiGuard has no signature for a threat you face — for example a brand-new or proprietary/internal application's traffic you want to detect, or a specific byte pattern/string unique to your network. (For a true zero-day, a custom signature only helps once you know the pattern; otherwise you rely on behavioural controls and rapid FortiGuard updates.)

Interview tip: mention tuning sensors to reduce false positives, and setting new signatures to monitor first to observe impact before switching them to block.

FortiGuard subscriptions (the UTP or Enterprise bundle) pay for two things: ongoing signature/engine database updates and access to real-time cloud-lookup services. When the license lapses, the engines do not crash — but their knowledge freezes and the cloud lookups stop responding.

• AntiVirus — keeps scanning with the last-downloaded signatures and engine; it stops receiving new malware definitions, so newly emerging threats can slip through.
• IPS — same behaviour: keeps inspecting with the stale signature set, with no protection against newly disclosed exploits.
• Application Control — runs on its local signature database too, so it keeps working but will not recognise newly added applications.
• Web Filter and DNS Filter — these depend on live FortiGuard cloud category lookups, so once the subscription lapses (and any short grace period ends) the rating service stops responding. By default, uncategorised/unrated traffic is then allowed (fail-open) — though that behaviour is configurable in the profile (you can choose to block when the rating service is unreachable). So category enforcement effectively breaks rather than the box crashing.

Analogy: the locally-stored, signature-driven profiles still run on an old map, while the cloud-rated ones lose their live GPS.

Interview tip: the key distinction is that signature-DB features (AntiVirus, IPS, Application Control) keep running but go stale, while cloud-lookup features (Web Filter, DNS Filter) lose their rating service — and how uncategorised traffic is then treated (allow vs block) is a configurable choice.

IPsec builds a tunnel in two negotiations:

• Phase 1 (IKE SA) creates a secure management channel and authenticates the two peers. Both sides must agree on: the authentication method (pre-shared key or certificate) and the actual PSK, the encryption algorithm (e.g. AES), the hash/integrity (e.g. SHA-256), the Diffie-Hellman group, the IKE version (v1/v2) and mode, and the SA lifetime.
• Phase 2 (IPsec SA) uses that secure channel to negotiate how the actual user data is protected. Both sides must match: the encryption + integrity proposal, the PFS setting and its DH group, the local/remote selectors (the subnets allowed in the tunnel), and the Phase 2 lifetime.

Think of Phase 1 as showing ID and setting up a private meeting room; Phase 2 is agreeing on the rules for the conversation inside it.

Interview tip: If a tunnel comes up in Phase 1 but Phase 2 fails, suspect mismatched selectors/subnets or PFS — a classic exam trap.

These describe how IKE Phase 1 negotiates:

• IKEv1 Main mode uses six messages and hides the peer identities inside encryption — more secure but slower, and with PSK it needs a fixed/known peer IP (because the PSK is tied to the source IP).
• IKEv1 Aggressive mode uses only three messages and is faster, but it sends the identity (and a hash of the PSK) in the clear, so it leaks who you are and is more exposed to offline PSK cracking.
• IKEv2 is the modern rewrite: fewer messages, built-in DPD and NAT-Traversal, EAP support, MOBIKE for roaming, and better reliability. It is the recommended default today and has no separate main/aggressive mode distinction.

You are forced into aggressive mode mainly with IKEv1 dialup/remote peers that have dynamic IPs and use a PSK with a peer-ID — IKEv1 main mode with PSK can't identify a peer by ID when the source IP is unknown. (IKEv2 handles dynamic-IP dialup cleanly, so the better fix is usually to move to IKEv2.)

Main mode is like a careful introduction behind a closed door; aggressive mode shouts your name across the room to save time.

Interview tip: Prefer IKEv2; only fall back to IKEv1 aggressive mode for legacy dynamic-IP PSK dialup peers that can't do IKEv2.

FortiGate can build an IPsec tunnel two ways:

• Policy-based IPsec — the tunnel is tied directly to a firewall policy with an IPSEC action. Traffic is encrypted only if it matches that specific policy's source/destination. It's compact but rigid.
• Route-based IPsec — the tunnel appears as a virtual tunnel interface. You then use it like any normal interface: add a route pointing the remote subnet at that tunnel interface and write normal firewall policies referencing it.

Route-based is the modern default because the virtual interface is far more flexible: you can run dynamic routing (OSPF/BGP) over it, support multiple subnets cleanly, do per-tunnel monitoring, enable redundancy/failover, and integrate it into SD-WAN and ADVPN. Policy-based simply can't do dynamic routing, SD-WAN, or ADVPN, and newer FortiOS releases default the VPN wizard to route-based.

Think of route-based as installing a real doorway you can route through, versus policy-based taping a one-off note to a single door.

Interview tip: Say "route-based gives a virtual tunnel interface, so it supports dynamic routing, SD-WAN, and ADVPN" — that's why it's the default.

Three IPsec helpers, each solving a different problem:

• PFS (Perfect Forward Secrecy) forces a fresh Diffie-Hellman key exchange every time Phase 2 rekeys, so keys aren't derived from the previous one. Prevents: if an attacker ever steals one key, they still can't decrypt past or future traffic.
• DPD (Dead Peer Detection) sends periodic keepalives to check the remote peer is still alive. Prevents: a "black hole" tunnel that looks up on one side but is dead on the other — DPD tears down the stale SA so the tunnel can re-establish instead of silently dropping traffic.
• NAT-Traversal (NAT-T) detects a NAT device in the path and wraps ESP inside UDP 4500. Prevents: tunnel failure when one peer sits behind a NAT/router, because raw ESP (IP protocol 50) has no ports and often can't traverse NAT.

PFS guards yesterday's secrets, DPD clears dead lines, NAT-T lets the tunnel survive behind a router.

Interview tip: Map each to its symptom — stolen key, half-dead tunnel, NAT in the path — that crisp mapping impresses interviewers.

A dialup IPsec VPN is designed for remote peers whose IP address is not known in advance — think branch offices on dynamic ISP IPs, or remote workers. The FortiGate acts as the dialup server and simply waits; the remote peers (the dialup clients) are the ones that always initiate the connection.

Contrast with a static site-to-site tunnel:

• Static (site-to-site): both peers have fixed, known public IPs, so either side can initiate, and each peer identifies the other by its IP address.
• Dialup: only the client initiates (the server's IP is fixed, the client's is not). Since the server can't identify the client by IP, peers are identified by a peer-ID / local-ID (a string, FQDN, or certificate). One dialup config on the server can serve many remote peers.

It's like a hotline: the office number is fixed and published, and remote callers dial in identifying themselves by name, not by their (changing) phone number.

Interview tip: Key contrast — dialup = client-initiated, identified by peer-ID; site-to-site = either-initiated, identified by fixed IP.

ADVPN (Auto-Discovery VPN) solves a hub-and-spoke scaling problem. Normally, for one branch (spoke) to reach another, all traffic must hairpin up to the hub and back down — wasting bandwidth and adding latency, especially for voice/video.

With ADVPN, spokes start with only a tunnel to the hub. When spoke A sends traffic toward spoke B, the hub recognizes both endpoints are spokes and sends a shortcut-offer (IKE informational) message telling the spokes each other's real public address. The two spokes then negotiate a dynamic, on-demand IPsec shortcut tunnel directly between themselves, and subsequent traffic flows spoke-to-spoke, bypassing the hub. Idle shortcuts time out and tear down automatically.

ADVPN needs route-based IPsec (with the phase1 auto-discovery-sender/auto-discovery-receiver settings) plus a dynamic routing protocol — typically BGP — so routes update when shortcuts appear, and next-hop information so spokes learn each other.

Think of the hub as a switchboard operator who connects two callers directly, then drops off the line.

Interview tip: The hub doesn't carry the shortcut traffic — it only brokers the introduction via shortcut messages; spokes build the direct tunnel themselves.

FortiGate SSL-VPN historically offered two ways to connect:

• Web mode (now branded Agentless VPN) — the user just opens a browser, logs into the SSL-VPN portal, and reaches internal apps through that web page (an HTTPS reverse-proxy). No client software is installed, but it only works for the web/app types the portal supports — no mapped drives or arbitrary thick-client access.
• Tunnel mode — the user runs FortiClient, which builds a full network tunnel and gives the device a virtual IP, so any application (RDP, SSH, file shares) works as if on the LAN.

Two related concepts:

• Split tunneling — only corporate-bound traffic goes through the VPN; normal Internet browsing goes out directly. This saves the firewall's bandwidth (vs. full-tunnel, where everything is routed through the FortiGate).
• Portal bookmarks — pre-defined links on the web portal (RDP, HTTP, SSH targets) so users click straight into approved internal resources.

Heads-up for current FortiOS: tunnel mode is being removed (gone on all models at 7.6.3) and Fortinet steers remote access to IPsec/ZTNA — so in interviews, define the modes but note tunnel mode is on its way out.

Web mode is a guest visitor badge; tunnel mode is a full employee keycard.

Interview tip: Agentless/web mode = browser, app-limited; tunnel mode = FortiClient, full access; split tunnel saves bandwidth — and flag that tunnel mode is deprecated in FortiOS 7.6.

Fortinet has been steadily phasing out SSL-VPN, largely because it has been a repeated target of exploits. The arc in FortiOS 7.6:

• 7.6.0 / 7.6.1 — on FortiGate models with 2 GB of RAM or less (entry-level units such as the 40F/60F/61F families, with 7.6.1 widening the list), both SSL-VPN tunnel mode AND web mode were removed from the GUI and CLI. On those small models the feature is simply gone, and the migration path there is IPsec dialup.
• 7.6.3 — Fortinet removed SSL-VPN tunnel mode on ALL FortiGate models and replaced it with IPsec VPN. The settings do not auto-upgrade — you must migrate the tunnel-mode config to IPsec before upgrading to 7.6.3. SSL-VPN web / Agentless mode survives on models that have enough RAM; it is tunnel mode specifically that was retired fleet-wide.

Fortinet is steering customers toward two replacements: IPsec VPN (modern IPsec can be configured to listen on TCP/443, so it still works through restrictive firewalls that only allow HTTPS) and ZTNA (Zero Trust Network Access) for per-application, posture-checked access. Both have a smaller attack surface than a public SSL-VPN web portal.

Think of it as Fortinet retiring a door that kept getting kicked in, and pointing you to a stronger one.

Interview tip: Be precise — on ≤2GB models SSL-VPN (both modes) went away at 7.6.0/7.6.1; tunnel mode was removed on all models at 7.6.3 and does not auto-migrate; web/Agentless mode survives on larger models; IPsec on TCP/443 is the drop-in replacement through HTTPS-only paths.

Because SSL-VPN tunnel mode does not auto-convert, you plan a clean cutover:

1. Audit the current SSL-VPN: who connects, what subnets/apps they need, split-tunnel ranges, user groups, MFA, and portal bookmarks.
2. Confirm the target model still supports your chosen replacement, read the official upgrade-path notes, and back up the config first.
3. Build IPsec dialup as the like-for-like remote-access replacement: a dialup IPsec phase1 with IKEv2, user-group auth + MFA, an assigned client IP pool, split-tunnel networks, and — importantly — configure it to listen on TCP/443 so remote users behind HTTPS-only networks still connect. Deploy FortiClient with an IPsec profile (push via EMS).
4. For higher security, layer in ZTNA for specific internal apps (per-app access proxy with FortiClient/EMS device-posture tags) instead of giving full network access.
5. Pilot with a small group, verify routing/DNS/policies, then migrate users in waves and decommission SSL-VPN.

It's like changing the locks: you cut new keys (IPsec/ZTNA), test them on a few doors, then hand them out before retiring the old lock.

Interview tip: Lead with "back up + audit, then IPsec dialup on TCP/443 via FortiClient/EMS, ZTNA for sensitive apps, pilot then phased cutover."

ZTNA (Zero Trust Network Access) follows the principle "never trust, always verify." On FortiGate it works through a ZTNA access proxy: instead of dropping a remote user onto the whole network, the FortiGate publishes specific internal applications and brokers each connection per-application, checking identity AND device health on every request.

The device-health part comes from FortiClient + EMS: the endpoint reports posture (OS patch level, AV running, certificate, etc.) and EMS converts this into ZTNA tags. The FortiGate policy then allows access only if the tag conditions are met.

Contrast with a traditional full-tunnel VPN:

• VPN authenticates once, then the device sits inside the network with broad access — a compromised laptop can reach everything (lateral movement).
• ZTNA grants least-privilege, per-app access, continuously re-verifies device posture, and never exposes the full network.

VPN is one ID check at the front gate; ZTNA re-checks your badge at every single room.

Interview tip: Emphasize continuous, per-application verification with posture tags vs. the VPN's one-time auth and broad network access.

If Phase 1 completes but Phase 2 fails, IKE authenticated the peers but the two sides cannot agree on the IPsec (Phase 2) SA. Run the IKE debug:

1. diagnose vpn ike log-filter dst-addr4 198.51.100.2 (filter to the peer so the output is readable).
2. diagnose debug application ike -1
3. diagnose debug enable
4. Trigger interesting traffic, then read the negotiation messages (look for NO_PROPOSAL_CHOSEN or selector/proxy-ID errors).

Usual culprits:

• Phase 2 proposal mismatch: the encryption/authentication transform (for example AES256-SHA256) must match on both ends.
• PFS mismatch: if one side enables Perfect Forward Secrecy with a DH group and the other does not, or they use different groups, Phase 2 fails.
• Quick-mode selector / subnet mismatch: the local and remote selectors (proxy IDs) must mirror exactly; a /24 versus /25 difference breaks it.

Stop with diagnose debug disable afterward. Analogy: both sides agreed to meet, but disagree on the exact room.

Interview tip: Mismatched proxy-ID selectors are the most common Phase 2 killer.

This is a defensive hardening exercise. First confirm exposure by checking the FortiOS version and build (get system status) against Fortinet's PSIRT advisory for each CVE. CVE-2024-21762 is an unauthenticated out-of-bounds-write vulnerability in SSL-VPN (sslvpnd) that can lead to remote code execution; CVE-2022-40684 is an authentication-bypass affecting the administrative interface (HTTP/HTTPS GUI and REST API). Check whether SSL-VPN is actually enabled and whether admin access is reachable from the internet, and review logs for suspicious admin logins or unexpected config changes.

Compensating controls (defensive only):

• Patch to the fixed FortiOS build — this is the only real remediation.
• Disable SSL-VPN if it is unused; note Fortinet is deprecating SSL-VPN tunnel and web modes on low-memory/entry-level models (in 7.4/7.6) in favour of IPsec dial-up, so plan that migration.
• Restrict administrative access with trusted hosts and local-in policies.
• Use a dedicated management interface, and never expose the admin interface (or SSL-VPN) directly to the internet.

Interview tip: Patching is the fix; trusted-hosts and no-internet-admin are mitigations, not substitutes for patching.

FGCP (FortiGate Clustering Protocol) is Fortinet's native high-availability protocol that links two or more identical FortiGates (same model and firmware) into one logical cluster sharing a virtual identity, so if one fails the other keeps traffic flowing. The units sync configuration and (optionally) sessions over dedicated heartbeat links.

Active-Passive (A-P): one unit (primary) handles all traffic while the others stand by fully configured and ready. On failure the backup takes over in seconds. Simple, predictable, the most common choice — it gives you redundancy/failover.

Active-Active (A-A): the primary still owns the routing and session ownership but distributes proxy-based inspection workload (such as antivirus and other proxy UTM) across the secondary units, so you also gain some load distribution of CPU-heavy inspection.

Think of A-P as a spare driver waiting, and A-A as two drivers sharing the heavy lifting.

Interview tip: A-P = redundancy only; A-A = redundancy plus distribution of inspection load. Most enterprises run A-P for simplicity.

With override disabled (the default), FGCP elects the primary by comparing, in order: (1) monitored-interface (link) status — fewer failed monitored ports wins; (2) HA uptime — the unit that has been up longest (beyond a stabilization threshold) wins; (3) device priority — higher value wins; (4) serial number — highest wins as the final tie-breaker.

Because uptime is checked before priority, a freshly rebooted unit will not preempt the current primary. Enabling override reorders this so the comparison becomes monitored interfaces, then device priority, then uptime, then serial — this lets you force a specific preferred unit to always become primary (deterministic), at the cost of an extra failover when it rejoins.

Heartbeat interfaces carry config sync, session sync and the keepalives that tell each unit the peer is alive. If all heartbeat links fail, both units think they are alone and both go active — a split-brain causing IP/MAC conflicts. That is why you always use at least two dedicated heartbeat links.

Interview tip: by default uptime beats priority; enable override to make priority decide.

Session pickup (set session-pickup enable) makes the primary continuously replicate its session table to the backup over the heartbeat link. So when a failover happens, established TCP sessions survive — downloads and SSH sessions keep flowing instead of being reset. Without it, the config still fails over but every existing session must be re-established.

By default, session pickup syncs longer-lived TCP sessions. session-pickup-connectionless extends syncing to UDP and ICMP (connectionless) sessions, and session-pickup-expectation covers expected/pinhole sessions (e.g. FTP/SIP data channels) so those also survive failover.

You might not enable session pickup on a small/low-resource FortiGate because constantly replicating the session table consumes extra CPU, memory and heartbeat bandwidth; on a busy box this overhead can hurt performance. If a few seconds of session re-establishment is acceptable, leaving it off is a valid trade-off.

Interview tip: session pickup keeps sessions alive across failover but costs sync overhead — consider disabling it on resource-constrained units.

In FGCP you tell the cluster which ports matter by adding them as monitored interfaces (link/port monitoring). Each unit watches the link state of those ports. If a monitored interface on the primary goes down, the primary's effective election score drops, and FGCP triggers a failover to the backup whose monitored links are all up — this protects against an upstream cable or switch failure that the primary itself can't otherwise detect.

The key to seamless failover is the virtual MAC (vMAC). Each cluster interface uses an FGCP-derived virtual MAC instead of the physical port MAC, so the same IP and MAC are presented regardless of which unit is active. When the backup becomes primary, it owns these vMACs and sends gratuitous ARP so downstream switches update their MAC/CAM tables to the new active unit's ports. Endpoints' ARP caches stay valid — they never know a switch happened.

Think of the vMAC as a shared phone number that simply rings on whichever unit is on duty.

Interview tip: gratuitous ARP plus the shared virtual MAC is what keeps switches pointing the right way after failover.

FGCP builds a tightly-coupled cluster of identical FortiGates that share one configuration and a virtual identity and elect a single primary — it is the standard chassis-redundancy HA. FGSP (FortiGate Session Life Support Protocol / Session-Sync) is looser: the FortiGates remain independent, keep their own configurations, and simply synchronize session tables (and optionally other state) with each other. There is no single primary — each unit forwards its own traffic.

You choose FGSP when you need to scale beyond a simple A-P pair, especially with asymmetric or load-balanced traffic: e.g. multiple FortiGates sitting behind external/ECMP load balancers or in active-active data-center designs, where return traffic may hit a different unit than the outbound flow. FGSP session sync lets any peer recognize and continue a session another unit started, avoiding drops from asymmetry. (FGSP can also be layered on top of FGCP clusters in larger designs.)

Think of FGCP as one team with a captain, and FGSP as peers sharing notes so any of them can continue your case.

Interview tip: FGCP = config + chassis HA with one primary; FGSP = independent units sharing session state, ideal for asymmetric/load-balanced scale-out.

SD-WAN bundles multiple WAN links (broadband, MPLS, LTE) into intelligent virtual transport. Links are added as members and grouped into SD-WAN zones, which you then reference in routing and firewall policies instead of individual ports — so you write policy once for all WANs.

Performance SLA health checks actively probe each member (ping, HTTP, DNS, etc.) to a target and measure latency, jitter and packet loss; a member that breaches your SLA thresholds is marked out of compliance and steering avoids it.

SD-WAN rules steer specific traffic by strategy: Manual (admin picks the member order), Lowest Cost (SLA) (use the cheapest/highest-priority member that still meets SLA), Best Quality (pick the member with the best measured metric), and Maximize Bandwidth (load balance) (spread sessions across compliant members).

The implicit rule is the catch-all at the bottom: traffic that matches no explicit SD-WAN rule is forwarded using the default member/load-balance method (e.g. source-IP) over the SD-WAN's installed routes.

Interview tip: health checks decide which links are usable; rules decide which usable link wins; the implicit rule catches everything else.

Application-aware steering uses FortiGate's application control / deep inspection (and Internet Service / ISDB and FQDN objects) to identify the actual application — Microsoft 365, Teams, SAP, YouTube — inside an SD-WAN rule. You then match on that application and steer it by SLA or quality: e.g. send Teams/voice over the lowest-jitter link and bulk backups over the cheaper link. Because an app is only positively identified after the first few packets, FortiGate steers initial packets by ISDB/learned-app data and re-evaluates as the application is recognized.

ADVPN (Auto-Discovery VPN) solves hub-and-spoke inefficiency. Spokes build permanent IPsec overlays to a hub; when two spokes need to talk, the hub sends shortcut messages so the spokes negotiate a dynamic, on-demand direct tunnel between themselves, bypassing the hub. It scales because you do not pre-build a full mesh.

In a modern (2024-2026) design, each ADVPN overlay is an SD-WAN member, so Performance SLA and application-aware rules choose the best overlay and ADVPN gives direct spoke-to-spoke paths — low latency for voice/video without hairpinning through the hub.

Interview tip: ADVPN = on-demand spoke-to-spoke shortcuts; SD-WAN over those overlays adds per-application, SLA-based path selection.

A VDOM (Virtual Domain) partitions one physical FortiGate into multiple independent virtual firewalls, each with its own interfaces, routing table, policies and admins — like running several firewalls on one box.

Split-task VDOM mode is a lightweight two-VDOM split: a management VDOM (root) for management/admin functions and a traffic VDOM (FG-traffic) for firewall policies and traffic, used to isolate management without full multi-tenancy. Multi-VDOM mode lets you create many fully independent VDOMs for true segmentation or multi-tenancy.

The management VDOM is the one the FortiGate uses for its own outbound services — FortiGuard updates, NTP, logging, DNS. Inter-VDOM links are internal virtual interface pairs that let two VDOMs route to each other inside the box (controlled by policies) without external cabling. Per-VDOM resource limits cap objects like sessions, policies, users and VPN tunnels so one tenant cannot starve another.

VDOMs are justified when you need separate routing/policy domains or true tenant isolation — MSPs, distinct business units, or overlapping IP ranges — on shared hardware.

Interview tip: split-task = traffic vs management separation; multi-VDOM = full multi-tenant segmentation; inter-VDOM links route between them internally.

When multi-VDOM is enabled, the configuration splits into two scopes. Global scope holds settings that apply to the whole physical appliance regardless of VDOM — there is one copy shared by all. Per-VDOM scope holds settings that belong to a single virtual firewall, so each VDOM has its own independent copy.

Global examples: hostname, firmware, HA configuration, admin accounts and access profiles, FortiGuard/licensing, physical interface hardware settings, GUI/console settings, and the hardware-switch fabric. You reach it with config global.

Per-VDOM examples: firewall policies, the routing table and static/dynamic routing, NAT/IP pools, security profiles (AV, IPS, web filter), VPN tunnels, DHCP servers, address objects and the interface IP/role within that VDOM. You enter it with config vdom then edit VDOM-NAME.

Think of global as the building's shared power and front door, and per-VDOM as each tenant's own locked office.

Interview tip: remember a clean pairing — admins, HA and FortiGuard live in global; firewall policies and routing live per-VDOM.

FortiManager is centralized configuration/orchestration for many FortiGates. ADOMs (Administrative Domains) group devices (by customer, region or firmware) so teams manage only their own set. You build policy packages — reusable firewall policy + object sets — and install them to one or many devices at once for consistency.

FortiManager keeps a Device DB (the configuration it intends a device to have) separate from the device's running config. Import pulls the live config into the Device DB; install pushes the Device DB (and policy package) out to the FortiGate. A diff between them shows configuration drift before you commit, which is what makes fleet changes safe and auditable.

FortiAnalyzer is centralized logging and analytics: every FortiGate streams logs to it, and you get FortiView drill-downs, historical search, scheduled SOC/compliance reports, and incident/threat correlation.

Together: FortiManager pushes consistent policy and FortiAnalyzer gives single-pane visibility — the standard way to run a multi-site fleet.

Interview tip: import = pull device into FortiManager; install = push FortiManager to device; FortiManager = config, FortiAnalyzer = logs/reports.

diagnose debug flow shows in real time how the FortiGate processes a packet end to end. A typical sequence is:

1. diagnose debug flow filter addr 203.0.113.10 (and optionally diagnose debug flow filter port 443) to focus on the target.
2. diagnose debug flow show function-name enable for more detail.
3. diagnose debug enable, then diagnose debug flow trace start 20 to capture 20 packets.

The output narrates each step: which route is chosen, which policy id matched, whether NAT was applied, and any UTM verdict such as a web-filter or IPS block. A line saying the session is denied by a policy, or that web filtering blocked the URL category, gives you the answer.

It is like a flight recorder for one packet. Always stop afterwards with diagnose debug flow trace stop and diagnose debug disable so you are not left in debug mode.

Interview tip: Set a filter first so you are not flooded with traffic.

diagnose sniffer packet is FortiGate's built-in packet capture (like tcpdump). The syntax is diagnose sniffer packet [interface] '[filter]' [verbosity] [count] [timestamp]; use any for all interfaces.

Verbosity levels build up detail:

• 1: print header only.
• 2: print header plus IP payload data.
• 3: print header plus Ethernet frame data.
• 4: print header plus the interface name.
• 5: print header, IP payload data, and interface name.
• 6: print header, Ethernet frame data, and interface name (most detailed).

The filter uses pcap (BPF) syntax. To capture one host/port pair: diagnose sniffer packet any 'host 10.1.1.5 and port 443' 4 0 a. You can combine terms with and/or, for example 'host 10.1.1.5 and host 8.8.8.8'. Set count to 0 for continuous capture (stop with Ctrl-C), and a for absolute UTC timestamps.

Interview tip: Verbosity 4 is the everyday sweet spot (headers plus interface name).

The most likely cause is missing hairpin NAT (NAT loopback). From the internet the VIP DNAT works, but when an internal LAN host hits the same public VIP address, the request and reply take asymmetric paths and break, because the server replies directly to the internal client with its private IP rather than back through the firewall.

To confirm, run a flow trace from an internal test host: diagnose debug flow filter addr [server-public-IP], then diagnose debug enable and diagnose debug flow trace start 10 — or capture on the LAN interface with diagnose sniffer packet. You will typically see the SYN reach the server but no properly translated reply, or a session that never completes.

The fix is a hairpin policy: a firewall policy with the LAN interface as both incoming and outgoing interface, source = internal subnet, destination = the VIP object, and NAT (source NAT) enabled so the server replies through the FortiGate.

Interview tip: External works, internal fails to a VIP = think hairpin NAT immediately.

Reverse path check fail means the FortiGate's anti-spoofing RPF (Reverse Path Forwarding) check rejected the packet. In the default strict mode (feasible-path RPF disabled) the firewall verifies that the best return route for the source IP points back out the same interface the packet arrived on. If it does not, the firewall treats the source as spoofed or mis-routed and drops it.

The common cause is asymmetric routing, where traffic enters one interface but the route table would send replies out another (dual-ISP or redundant links).

Options to resolve:

• Fix routing: add or correct the return route so it matches the ingress interface (the cleanest fix).
• Switch to loose / feasible-path RPF: enable feasible-path RPF (global config system settings → set strict-src-check disable is the default loose mode; strict mode is set strict-src-check enable) so any valid route to the source is accepted, not only the best one.
• Disable the source check on the interface (interface-level set src-check disable) or allow asymmetric routing where a redundant-link design genuinely needs it — use sparingly, as it weakens spoofing protection and stateful inspection.

Interview tip: Prefer fixing routing over loosening RPF; loosening reduces spoofing protection.

The session table is the FortiGate's live record of every connection. To find one flow, set a filter first so you do not dump everything:

1. diagnose sys session filter clear (start clean).
2. diagnose sys session filter src 10.1.1.5 and/or diagnose sys session filter dst 203.0.113.10 and diagnose sys session filter dport 443.
3. diagnose sys session list to display matching sessions (state, NAT, policy id, expiry, counters).

For a quick count, use diagnose sys session stat.

To clear a stuck or stale session, keep the same filter and run diagnose sys session clear, which deletes only the filtered sessions so the client can re-establish cleanly. Always re-check with another diagnose sys session list.

Analogy: it is the firewall's call log; you filter to one number, read its details, then hang up the frozen call.

Interview tip: Always set the filter before clear, or you will flush every session on the box.

Conserve mode is a self-protection state the FortiGate enters when memory runs low. To protect stability it stops admitting new sessions to proxy-based inspection (and depending on the av-failopen setting it either passes that traffic without proxy inspection, fail-open, or blocks it, fail-close), which looks like slowness and dropped new connections.

To confirm: run get system performance status and check CPU and especially memory usage. Use diagnose hardware sysinfo memory for detail and diagnose sys top to find the memory-hungry process. Event logs and diagnose debug show conserve-mode entry/exit events.

The triggers are kernel memory thresholds: the FortiGate enters conserve mode when used memory crosses the red threshold (default around 88 percent) and leaves when it drops back below the green threshold (default around 82 percent); there is also an extreme threshold (around 95 percent) at which it starts dropping sessions more aggressively. These are tunable under config system global (memory-use-threshold-red / green / extreme).

Analogy: the firewall is short on RAM and refuses new guests until it can breathe.

Interview tip: Quote the red-in / green-out threshold idea, not just the exact numbers.

On FortiGate models with an NPU (Network Processor), offloaded sessions take the fast path in hardware; if a session falls back to the CPU it is on the slow path and throughput drops.

Check the session itself with diagnose sys session list and read the session flags. An offloaded session typically shows an npu info block (with offload flags set in each direction); when a session is not offloaded, the no_ofld_reason field tells you exactly why. Also use the model-specific NPU stats, for example diagnose npu np6 session-stats <npu-id> and diagnose npu np6 sse-stats <npu-id> (use np7 on newer platforms), to see hardware session counts.

Common reasons offload is denied: UTM/proxy inspection (antivirus, web filter, IPS — anything that needs the CPU to read the payload), a per-session capture (sniffer), asymmetric routing, certain VPN/encryption combinations the NPU cannot handle, or auto-asic-offload disabled on the policy.

Analogy: the express lane is only for simple traffic; deep inspection forces a detour through the CPU.

Interview tip: The no_ofld_reason flag on the session is the single fastest answer.