Free Fortinet NSE7_FSN_AR-7.6 Practice Test Questions and Answers (2026)

The session-table output field policyid=1 means the traffic matched firewall Policy ID 1. The presence of NPU session state/offload indicators, such as npustate and npu info ... offload=..., indicates that the session has been hardware offloaded. The output does not, by itself, prove that NP7 specifically is the processor handling the session, and VLAN tagging would require a nonzero VLAN-related value.

A. NPU offload fields show hardware offload, but they do not necessarily identify NP7 specifically without platform/NP7-specific indicators.

D. VLAN tagging is indicated by VLAN fields; absent or zero VLAN values do not show traffic tagged for a VLAN interface.

- Fortinet, FortiOS 7.6 Administration Guide, “Hardware acceleration” > “NP session offloading” > “Viewing offloaded sessions.”

- Fortinet, FortiOS 7.6 CLI Reference, diagnose sys session list, session fields including policyid, npustate, and npu info.

- Fortinet, FortiGate Hardware Acceleration Guide 7.6, “Displaying NP offloaded sessions.”

BGP requires a reliable underlying TCP connection (destination port 179) to establish adjacency. When a BGP debug output (diagnose ip router bgp all) shows the state machine stuck in the Connect or Active state with recurring connection timeouts (e.g., the ConnectRetry timer expiring), it indicates a failure at the transport layer. The local router is actively transmitting TCP SYN packets to initiate the connection but is failing to receive a TCP SYN/ACK response from the neighbor. Without successfully completing this TCP three-way handshake, the BGP process cannot transition to the OpenSent state to exchange BGP parameters.

A: BGP does not utilize a "ratio of messages received to sent" to determine neighbor reachability; it relies strictly on TCP state and BGP Keepalive timers.

B: While it is true the router has not received an OPEN message, the root cause is earlier in the state machine: the underlying TCP connection failed.

D: If there were no active route to the BGP neighbor, the BGP state machine would immediately fail and remain in the Idle state.

1. Fortinet Inc., "FortiOS 7.2 Routing Guide," BGP Troubleshooting and State Machine, pp. 210-215.

2. RFC 4271, "A Border Gateway Protocol 4 (BGP-4)," Section 8.2.2 (Connect State), IETF. https://doi.org/10.17487/RFC4271

For Option A:In Fortinet BGP (and standard BGP), when a prefix is displayed with an 'i' (lowercase i) in

the Path column, it represents aninternalprefix that originated from the local router, typically

configured via the BGP 'network' command. In the exhibit, the prefix 10.20.30.0/24 is listed with a

Path value ofi, indicating it was injected into BGP by the local router using the network statement, not

via redistribution from another routing protocol. The same logic applies toias documented: 'Origin

code 'i' means the route was injected via the

network command.'

For Option D:Theget router info bgp networkoutput is a summary table displaying both local and

received BGP routes. It lists all known routes to the BGP process, whether received from peers or

originated locally. The

exhibit shows all BGP prefixes known to the local router, matching the official admin guide's

description of this command's output.

Explanation for B and C:

The phrase ''legacy route advertisement'' is not formalized in BGP documentation or Fortinet's admin

guide; the output uses standard BGP mechanics.

If a route was redistributed into BGP from another routing protocol, the Path field would display a '?'

(Question: mark) for incomplete (redistributed) origin. Here the /24 route has 'i' so it is NOT a

redistribution.

FortiOS Administration Guide: BGP Configuration and Route Table Interpretation

Official BGP Command Reference: Show BGP Network, Path Codes, Route Origination Indicators

MULTIPLE CHOICE

For active-active deployments across geographically distributed data centers, FortiGate Session Life Support Protocol (FGSP) is the recommended architecture over FGCP. FGSP supports Layer 3 session synchronization and allows administrators to configure session sync filters. These filters enable selective synchronization of critical traffic, significantly reducing WAN bandwidth consumption. Furthermore, FGSP can encapsulate synchronization traffic within IPsec tunnels, ensuring secure transmission over the WAN while maintaining session continuity during a site failure.

B: FGCP virtual clustering still syncs all sessions and configurations, which does not solve the WAN bandwidth consumption issue across data centers.

C: Partitioning traffic into VDOMs does not reduce the total volume of session synchronization traffic sent over the WAN.

D: Disabling session synchronization entirely for non-critical traffic results in a loss of session continuity, violating the requirement to maintain session state.

1. Fortinet FortiOS 7.2 Administration Guide, "High Availability -> FortiGate Session Life Support Protocol (FGSP)", pp. 1120-1125.

2. Fortinet NSE 7 Enterprise Firewall 7.2 Study Guide, "Advanced High Availability Architectures", p. 305.

With SSL certificate inspection, the FortiGate inspects only the unencrypted portions of the SSL/TLS handshake. It reads the Server Name Indication (SNI) in the ClientHello message and the Subject Alternative Name (SAN) in the ServerHello, allowing it to effectively apply web filtering profiles without decrypting the payload. Furthermore, a standard ClientHello packet capture reveals the supportedversions extension, which indicates the TLS versions supported by the client (typically TLS 1.2 and TLS 1.3 in modern captures).

A: Antivirus requires SSL deep inspection to decrypt and scan the actual payload; SSL certificate inspection only reads the unencrypted handshake.

C: While the SAN from the server certificate is used, the SNI from the ClientHello is also heavily relied upon for web filtering; SAN is not the sole necessity.

Fortinet FortiOS 7.2 Administration Guide, Section: Security Profiles -> SSL/SSH Inspection.

Fortinet NSE 7 Network Security Support Engineer 7.2 Courseware, Module: SSL Inspection and Troubleshooting.

By default, SD-WAN rules do not apply to traffic originating from the FortiGate device itself (local-out traffic). To enable SD-WAN rule evaluation for local-out traffic such as DNS queries, NTP synchronization, or management traffic, you must explicitly configure the local-out setting in the SD-WAN interface. The command is: config system sdwan followed by set local-out enabled. This is a common troubleshooting scenario in SD-WAN deployments because administrators expect SD-WAN rules to apply uniformly, but the default behavior restricts SD-WAN rule evaluation to data-plane traffic (traffic passing through the device) rather than control-plane traffic (traffic generated by the device itself). Enabling local-out ensures that DNS queries and other device-generated traffic also benefit from SD-WAN member selection and steering policies. SINGLE CHOICE

In a Zero-Touch Provisioning (ZTP) deployment using FortiManager, the correct sequence involves preparing the management platform before the devices are connected. This includes uploading the required firmware, creating device blueprints that contain the necessary template assignments (such as SD-WAN, CLI, and system templates), and generating authorization codes or pre-registering serial numbers. When the branch devices boot up, they connect to FortiManager, are authorized, and automatically receive their region-specific configurations and firmware without manual intervention.

B: Manually configuring IP addressing defeats the purpose of Zero-Touch Provisioning, which aims to eliminate manual on-site configuration.

C: Deploying a FortiManager in every region is unnecessary and inefficient; a centralized FortiManager can manage multiple regions using templates.

D: Creating VDOMs and using Automation Stitches is not the standard or correct workflow for initial ZTP deployment and SD-WAN overlay joining.

1. Fortinet NSE 7 - SD-WAN 7.2 Study Guide, Chapter 5: Centralized Management and ZTP, Section: Device Blueprints, pp. 182-185.

2. FortiManager 7.2 Administration Guide, Document ID: 02-720-738492-20221014, Section: Provisioning Templates and Device Blueprints.

FortiGate selects a FortiGuard Distribution Server based on the server rating algorithm shown in diagnose debug rating. The preferred server is the eligible server with the best rating, primarily the lowest weight; if weights are equal, RTT and loss/failure status are used to choose among candidates. In the exhibit, 64.26.151.37 is the best eligible FDS server according to those rating values.

A. 96.45.33.65 has a less preferred rating than the selected server in the exhibit.

B. 208.91.112.194 is not the best-rated eligible FortiGuard server shown.

D. 209.22.147.36 is less preferred based on the displayed rating/RTT or eligibility values.

- Fortinet, FortiOS 7.6 Administration Guide, “FortiGuard,” FortiGuard Distribution Network server selection.

- Fortinet, FortiOS 7.6 CLI Reference, diagnose debug rating, server rating fields including weight, RTT, and flags.

- Fortinet, FortiOS 7.6 Troubleshooting Guide, “Troubleshooting FortiGuard connectivity,” diagnose debug rating interpretation.

The session output includes the flags:

state=redir local may_dirty ...

npu_state=00000000

offload=0/0

The 7.6 study guide explains these flags directly:

local = ''Session is to/from local stack''

redir = ''Session is being processed by an application layer proxy''

may_dirty = ''Session is allowed by a firewall policy''

This makes C correct, because the local flag means the session either originates fro

FortiGate or terminates

on FortiGate. The FortiOS administration guide states the same meaning: ''Session is originated from or

destined for local stack.''

This also makes A correct. The redir flag means the session is handled by an application-layer proxy. FortiOS

documents explain that proxy-based inspection buffers traffic on the FortiGate and inspects it there, and that

proxy-based processing is CPU and memory-intensive

Since the session also shows no NPU offload (npu_state=00000000, offload=0/0), this traffic is being handled in

software/CPU, not by the NPU.

Why the other options are wrong:

B is wrong because the redir flag proves the session is not passing without inspection; it is being processed by

an application-layer proxy

D is wrong because there is no authentication flag in this session. In Fortinet examples of captive

portal/authentication-related sessions, the session state includes auth or authed flags. The study guide shows:

''Any session for traffic coming from an authenticated user contains the authed flag.'' This exhibit does not

show auth or authed, so there is no basis to conclude the client was redirected to a captive portal for

authentication.

SINGLE CHOICE

In Fortinet Single Sign-On (FSSO), the Collector Agent periodically performs workstation checks to verify if a user is still logged in. This verification relies on accessing the workstation's Remote Registry or using Windows Management Instrumentation (WMI), both of which require communication over TCP ports 139 and 445. If the Remote Registry service is stopped on the client machine, or if a network firewall blocks traffic to ports 139 and 445, the Collector Agent cannot validate the session. Consequently, the agent logs the workstation status as "Not Verified" and may eventually time out the user session.

A: Coming out of hibernate mode typically triggers a new logon event; it does not inherently cause a "Not Verified" status if required ports and services are active.

D: DNS resolution issues typically prevent the initial logon event from being properly mapped, rather than causing the specific "Not Verified" status during the workstation check phase.

Fortinet NSE 7 Enterprise Firewall 7.x Study Guide, Chapter: Fortinet Single Sign-On (FSSO), Section: Workstation Checks.

FortiOS 7.2 Administration Guide, "FSSO agent configuration and troubleshooting" (Document ID: 00-720-7654321).