Free FCSS_NST_SE-7-6 Practice Test

Heartbeat messages are keepalives exchanged between the FSSO Collector Agent (CA) and the FortiGate to verify that the connection is active. These messages can be observed from both ends of the connection. On the FortiGate, enabling the FSSO real-time debug (diagnose debug application fsso -1 and diagnose debug enable) will display the heartbeat packets being received. On the Windows server running the Collector Agent, the agent's own log files (collectoragent.log) record these keepalive events, which is essential for troubleshooting from the server side.

A. The command diagnose debug authd fsso list is used to display the list of FSSO-authenticated users currently cached on the FortiGate, not for viewing real-time protocol messages.
D. Heartbeats are an intrinsic part of the FSSO communication protocol to maintain the connection state. They are enabled by default when the FSSO fabric connector is configured and do not require a separate manual command to be enabled.

Fortinet Single Sign-On (FSSO) 7.6.0 Administration Guide, page 51, "Troubleshooting > Collector agent debug log". This section describes the collectoragent.log file which contains information about keepalives sent to FortiGates.

FortiOS Handbook 7.6.1, User & Authentication Guide, "FSSO > FSSO troubleshooting". This section details the use of diagnose debug application fsso -1 to view communication between FortiGate and the collector agent, which includes heartbeats.

The debug output displays the local FortiGate receiving an OSPF Hello packet from a remote peer with the header field AuType 0. In the OSPF protocol, Authentication Type 0 signifies Null authentication (no authentication). The debug concludes with the error message Authentication type mismatch, indicating that the local device rejected the incoming packet. Because the remote peer is sending Hello packets without authentication, the local FortiGate must be expecting an authenticated packet—either cleartext (Type 1) or MD5 (Type 2). This confirms that the local device has authentication enabled while the remote device does not, resulting in a configuration mismatch.

A. The exhibit explicitly shows the received OSPF header contains AuType 0, proving the remote peer is using Null authentication (no authentication), not cleartext or MD5.

C. If the local FortiGate had no authentication configured, it would successfully process the AuType 0 Hello packet instead of generating an "Authentication type mismatch" drop error.

IETF RFC 2328 (OSPF Version 2): Section 8.2 "Receiving Protocol Packets" and Appendix D "Authentication". Specifies that AuType 0 corresponds to Null authentication, and mismatches in the AuType field will cause the packet to be discarded. (https://datatracker.ietf.org/doc/html/rfc2328)

Fortinet FortiOS 7.2 Administration Guide: "Routing > Dynamic Routing > OSPF". Outlines OSPF adjacency requirements and troubleshooting, confirming that differing authentication types between neighbors will explicitly prevent OSPF state formation and trigger mismatch debug logs.

The exhibit displays the config system fortiguard configuration, where the command set webfilter-force-off enable is currently active. According to official Fortinet documentation, the webfilter-force-off setting globally disables the web filtering service. When this parameter is enabled, the FortiGate device forcibly bypasses all web filtering functions, even if a valid web filter profile is actively applied to a matching firewall policy. Consequently, traffic passes through the policy completely uninspected by the web filter engine. To resolve this issue and resume normal web traffic inspection, the administrator must reverse this configuration by running set webfilter-force-off disable.

B. Increase webfilter-timeout: This command adjusts the maximum time the FortiGate waits for a FortiGuard rating server response; it does not turn the bypassed inspection engine back on.

C. Enable fortiguard-anycast: Anycast optimizes routing by automatically connecting the FortiGate to the nearest rating server. While it improves connectivity, it cannot override a forcibly disabled inspection service.

D. Change protocol to TCP: Modifying the protocol (such as switching to HTTPS/TCP) dictates how the firewall communicates with FortiGuard servers, but it will not override the force-off command.

Fortinet Document Library: FortiOS 7.2 CLI Reference for config system fortiguard (Document ID: 94620). Outlines the syntax and default parameters for overriding FortiGuard features. Available at: https://docs.fortinet.com/document/fortigate/7.2.6/cli-reference/94620/config-system-fortiguard

Fortinet Knowledge Base: "Technical Tip: Disable FortiGuard Services Globally" (Article ID: 196898). Explicitly details that set webfilter-force-off enable forces Web Filtering to be turned off, bypassing any Web Filtering services provided by FortiGuard. Available at: https://community.fortinet.com/t5/FortiGate/Technical-Tip-Disable-FortiGuard-Services-Globally/ta-p/196898

The command get router info ospf neighbor displays the state and roles of OSPF neighbors on a FortiGate device.

• Option A is correct: The neighbors 0.0.0.12 and 0.0.0.15 show specific designated router roles (DROther and BDR) under the State column. These roles (Designated Router, Backup Designated Router, and DROther) are exclusive to multi-access broadcast networks, meaning at least one interface (wan1 or wan2) is configured as a broadcast network.
• Option B is correct: Neighbor 0.0.0.18 displays a state of Full/ -. The hyphen (-) indicates that no DR/BDR election occurs on this segment, which is the standard operation for point-to-point network links.

Option C is incorrect: While the local FortiGate might act as a DR on the wan1 or wan2 segments to achieve a Full state with a DROther or BDR neighbor, the output does not explicitly state or confirm the exact role of the local FortiGate itself.

Option D is incorrect: Neighbor 0.0.0.18 is on a point-to-point network (ToHub interface), denoted by the state Full/ -. Point-to-point networks do not elect or utilize a Designated Router (DR).

Fortinet Official Documentation: FortiOS Enterprise Firewall Study Guide, Section: OSPF Network Types (Broadcast vs. Point-to-Point).

Fortinet Official Documentation: Network Security Support Engineer Study Guide, Section: Routing Diagnostics and OSPF Neighbor States.

By default, FortiOS utilizes a loose Reverse Path Forwarding (RPF) check and disables asymmetric routing. User A passes because its traffic enters via wan1, and the reply traffic symmetrically exits wan1 via the default route. This satisfies both stateful inspection and the loose RPF check. Conversely, traffic from User B (entering wan2) and User C (entering port1) lacks specific return routes on their respective ingress interfaces. Consequently, the FortiGate defaults to routing replies out of wan1. This creates an asymmetric routing scenario. Because asymmetric routing is disabled by default, the stateful firewall drops the reply packets for User B and User C, resulting in a failure. Thus, statements B, C, and E accurately describe the default network security behavior.

A. FortiOS utilizes a loose Reverse Path Forwarding (RPF) check by default; strict RPF must be manually configured and enabled per interface to function.

D. Asymmetric routing is explicitly disabled by default in FortiOS, meaning the stateful firewall drops out-of-state asymmetric reply traffic rather than allowing it to successfully pass.

Fortinet Document Library, FortiOS 7.2 Administration Guide, Security Profiles -> Anti-Spoofing -> "Reverse path forwarding (RPF)".

Fortinet Document Library, FortiOS 7.2 Administration Guide, Network -> Routing -> "Asymmetric routing".

Fortinet Training Institute, NSE 4 FortiOS 7.2 Study Guide, Chapter 3: Routing.

The Fortinet Security Fabric relies on the FortiTelemetry protocol for inter-device communication. To join a FortiGate to the fabric, the "Security Fabric Connection" (FortiTelemetry) must be explicitly enabled on the connecting interface of the downstream device. This is a manual configuration step. By default, the downstream FortiGate initiates this connection to the upstream (root) FortiGate. This communication uses the FortiTelemetry protocol, which operates over TCP on port 8013. This port can be customized, but 8013 is the default. The initial discovery of fabric members on the same broadcast domain, however, uses UDP port 8014.

A. FortiTelemetry operates over TCP (port 8013), but Neighbor Discovery uses UDP (port 8014) for broadcasting to find other fabric-capable devices.
B. The default port for FortiTelemetry (TCP 8013) can be modified, but the port for Neighbor Discovery (UDP 8014) is fixed and cannot be changed.

1. Fortinet FortiOS 7.6.0 Administration Guide

Security Fabric > Building the Security Fabric > Authorizing a device.

Page 10: "On the downstream FortiGate

edit the interface that connects to the upstream FortiGate. In Administrative Access

enable Security Fabric Connection." This confirms that FortiTelemetry must be manually enabled (Answer C).

Page 10: "The Security Fabric uses the FortiTelemetry protocol to communicate between devices. FortiTelemetry

also known as the Security Fabric connection

is established on the downstream device and initiated towards the upstream device. The connection is a TCP connection on port 8013." This confirms the default protocol

port

and connection direction (Answer D).

2. Fortinet FortiOS 7.6.0 Administration Guide

Security Fabric > Security Fabric settings.

Page 21: "FortiGate devices can discover each other using UDP port 8014." This confirms that Neighbor Discovery uses UDP

making option A incorrect. It also implies the port is a standard

not a configurable one

which supports why option B is incorrect.

The provided exhibit displays the output of a FortiOS session table entry (via diagnose sys session list). The parameter policy_id=1 is explicitly visible in the second line, verifying that the session traffic matches Firewall Policy ID 1. Additionally, the npu info section shows offload=8/8 alongside in_npu=1/1 and out_npu=1/1. These values confirm that the session has met all acceleration requirements and its traffic is actively being hardware-offloaded to a Network Processing Unit (NPU) rather than being processed by the primary CPU.

A: The parameter vlan=0x0000/0x0000 indicates that the frames are untagged (native traffic), rather than explicitly tagged with a VLAN ID of 0000.

B: The offload=8/8 value uniquely identifies that an NP6 processor is handling the session offload. An NP7 processor would be denoted by offload=9/9.

Fortinet Document Library: FortiOS 7.0 Hardware Acceleration Guide, Section: "Displaying NP6 offloading information for a session". (Defines offload=8/8 as NP6 specific and details NPU status flags).

Fortinet Knowledge Base: Technical Tip: Possible reasons and resolutions for a specific session not being offloaded to NPU, Article ID: 202449. (Validates NPU offloading parameter definitions including policy_id, npu_state, and offload ratios).

The FortiGate FortiGuard server selection algorithm uses the weight and round-trip time (RTT) to determine the best server for rating queries. The server list output from diagnose debug rating is organized such that FortiGate prefers servers with the lowest weight value. If multiple servers share the same lowest weight, the FortiGate uses the lowest RTT as a tie-breaker to select the preferred server (which is positioned at the top of the list).

In this exhibit:

• Servers 64.26.151.37, 64.26.151.35, and 66.117.56.37 all share the lowest Weight of 10.
• Among these, 64.26.151.37 has the lowest RTT of 45 ms, making it the top-preferred server selected by the algorithm.

A is incorrect: 66.117.56.37 has a weight of 10 but its RTT is 75 ms, which is higher than 64.26.151.37 (45 ms).

B is incorrect: 208.91.112.194 has a higher weight of 20 and a higher RTT of 107 ms, making it less preferred.

C is incorrect: 209.22.147.36 has a higher weight of 20 and an RTT of 103 ms, so it is not chosen over weight 10 servers.

Fortinet Knowledge Base, Technical Tip: FortiGuard flags and meanings (Document ID: 104863).

Fortinet Official Courseware: FCSS - Network Security Support Engineer Study Guide, FortiGuard Section (Server Selection and Weights).

The diagnose debug application samld -1 output displays the SAML AuthnRequest generated by the FortiGate acting as the Service Provider (SP). In the provided XML payload, the Destination attribute is set to https://10.1.10.2/saml-idp/nst/login/, and the lasso:RemoteProviderID points to http://10.1.10.2/samlidp/nst/metadata/. These specific fields define the Identity Provider (IdP) entity and the Single Sign-On (SSO) URL where the SP directs the authentication request. Therefore, this output conclusively demonstrates that the IdP's IP address is 10.1.10.2.

A. Active Directory is used for authentication. The debug output only illustrates the SP-to-IdP request. It does not reveal the underlying backend identity store (such as Active Directory, LDAP, or local databases) that the IdP relies upon to authenticate the user.

B. The authentication request is for an SSL VPN connection. Although /remote/saml/login/ is the default endpoint for SSL VPN, FortiOS IPsec dial-up VPNs with SAML can utilize this exact same SP endpoint. Thus, SSL VPN cannot be definitively concluded.

C. The IdP IP address is 10.1.10.254. The IP 10.1.10.254 is mapped to the AssertionConsumerServiceURL, which dictates where the IdP should return the SAML response. This explicitly identifies 10.1.10.254 as the Service Provider (FortiGate), not the IdP.

Fortinet Community Knowledge Base, "Technical Tip: How to read SAML Debug output," Article ID: 146326. (Section: Solution -> specifically defines the parameter Destination="..." as the target URL to redirect to the Identity Provider).

FortiOS 7.4 Administration Guide, "SAML SP for VPN authentication." (Details the roles of the SAML parameters, confirming that the AssertionConsumerServiceURL represents the FortiGate SP endpoint waiting to consume the assertion, while the request destination routes to the external IdP).

In the IKEv2 protocol, the initial negotiation consists of two exchanges: IKESAINIT and IKEAUTH. The IKESAINIT exchange establishes a secure channel (the IKE SA) by negotiating cryptographic parameters and performing a Diffie-Hellman key exchange. Following this, the IKEAUTH exchange authenticates the peers and, critically, negotiates and establishes the very first CHILDSA. This first CHILDSA is the IPsec security association that protects the actual data traffic. Subsequent CHILDSAs are created using the CREATECHILDSA exchange.

A. The IKESAINIT exchange only establishes the parent IKE SA (the control channel); it does not create any CHILDSAs for data traffic.
B. The INFORMATIONAL exchange is used for control messages, such as error reporting or deleting SAs, not for creating them.
C. The CREATECHILDSA exchange is used to create additional CHILDSAs or to rekey existing ones after the initial IKEAUTH exchange is complete.

1. FortiOS 7.6.0 IPsec VPN Administration Guide, "IKEv2 protocol" section. This guide details the two initial exchanges, specifying that the first CHILDSA is created during the IKEAUTH exchange.

2. RFC 7296, "Internet Key Exchange Protocol Version 2 (IKEv2)", Section 1.2. This official standard states that the IKEAUTH exchange is used to "create the first CHILDSA".