FCSS_NST_SE-7-6 Practice Questions

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 OSPF: hello mapping: auth type 0 indicates that the local FortiGate has received an OSPF Hello packet from the remote peer (10.0.1.2) that has no authentication configured (auth type 0). For an adjacency to fail due to authentication, there must be a mismatch. If the remote peer is using no authentication, the local FortiGate must be configured to expect authentication (either cleartext or MD5). This situation constitutes an OSPF authentication configuration mismatch.

A. This is incorrect. The debug log explicitly shows the received packet from the remote peer has auth type 0, which means no authentication is configured on that peer.

C. If the local FortiGate also had no authentication configured, the authentication parameters would match, and they would likely form an adjacency (assuming other parameters match).

- FortiGate Infrastructure 7.6 Study Guide, Chapter 3: Routing, pages 168-170. (Discusses OSPF adjacency requirements, including matching authentication types).

- FortiOS Handbook 7.6, Advanced Routing Handbook, section "OSPF", subsection "OSPF troubleshooting". (Details OSPF debug messages and common adjacency issues like authentication mismatch).

- RFC 2328 - OSPF Version 2, Section D.3: Authentication. (Defines Authentication Type 0 as NullAuthentication).

The exhibit shows the command set webfilter-force-off enable within the firewall policy configuration. This setting explicitly disables web filtering for any traffic matching this policy, overriding the applied web filter profile. To enable web filtering inspection as intended by the administrator, this forceful override must be disabled. Disabling webfilter-force-off will allow the assigned webfilter-profile "default" to inspect the traffic as expected.

B. webfilter-timeout adjusts the time FortiGate waits for a FortiGuard rating; it does not enable or disable the inspection feature itself.

C. fortiguard-anycast is a global setting for communication with FortiGuard servers and does not control the web filter status on a specific policy.

D. The policy protocol is set to all, which includes TCP. Changing it specifically to TCP would not resolve the issue of the filter being forced off.

1. FortiOS 7.6.0 CLI Reference, FortiGate. (2024). config firewall policy section. p. 1032. The webfilter-force-off attribute is defined as "Enable/disable forcing disable of web filter for this policy."

The exhibit shows OSPF neighbors with states like "Full/DR" and "Full/DROther", which are specific to broadcast or NBMA networks. The presence of priority values and DR/DROther states confirms at least one interface participates in a broadcast network. Neighbor 0.0.0.18 shows state "Full/DR", indicating it is the Designated Router. The local FortiGate cannot be the DR since it sees 0.0.0.18 as the DR in its neighbor table.

B: Point-to-point networks don't use DR/BDR election or show DR/DROther states.

C: The local FortiGate sees 0.0.0.18 with "Full/DR" state, meaning 0.0.0.18 is the DR, not the local device.

- FortiGate Administration Guide 7.6, "OSPF Network Types and Neighbor States" section

- RFC 2328 "OSPF Version 2", Section 7.2 - DR and BDR Election Process

- Fortinet Technical Documentation NSE 7.6, "Dynamic Routing Protocol Configuration"

Reference:

Fortinet Technical Note: RPF Default Configuration and Routing Table Matching

FortiGate Administration Guide: Routing and Asymmetric Routing Controls

Community Knowledgebase: Route Lookups and RPF Enforcement on FortiOS

FortiTelemetry is a critical part of Security Fabric communications and requires explicit

configuration for each participating FortiGate interface. The administrative access setting

"fabric" (corresponding to FortiTelemetry) must be manually enabled per interface on both

upstream and downstream devices. This is performed in the GUI under Administrative

Access or via the CLI using the command set allowaccess fabric for the relevant network

interface. Without this step, FortiTelemetry communications will not occur on that interface.

Additionally, the default communication between downstream and upstream FortiGate units

in the Security Fabric is over TCP port 8013. This port is well-documented as the standard

for Security Fabric and FortiTelemetry connections, and must be open and permitted across

the network path for connectivity and status enforcement between units. The downstream

FortiGate initiates the connection to the upstream via this port unless otherwise configured.

This has also been documented as a PCI-relevant port, showing its default usage.

Other options:

Neighbor Discovery in FortiOS uses IPv6 ND protocol, not TCP.

FortiTelemetry port (8013) can be modified, but the interface Administrative Access for the

Security Fabric must be manually enabled; Neighbor Discovery port modification is not

documented as a supported change for FortiGate.

Reference:

FortiGate/FortiOS Administration Guide: Enabling FortiTelemetry (fabric) on interfaces

Fortinet Technical Tip: FortiTelemetry uses TCP port 8013 by default

PCI compliance documentation on port 8013 usage for Security Fabric

Fortinet Security Fabric setup procedures and interface options

The session table clearly shows "policyid=1", confirming that traffic matches Policy ID 1. The "npustate=0x4000000" flag indicates the session has been successfully offloaded to the Network Processor for hardware acceleration. The specific NPU state value confirms active offloading rather than just NPU capability. These are the two definitive facts visible in the session table entry.

A. No VLAN tagging information is visible in the session table entry shown.

B. The NPU state indicates offloading but doesn't specify which NPU model (NP6/NP7) is handling it.

- Fortinet FortiOS 7.6 CLI Reference Guide, "diagnose sys session list" command output interpretation, Session Table Fields section

- Fortinet Hardware Acceleration Guide 7.6, NPU Offloading States and Flags, Chapter 3

- FortiGate Administration Guide 7.6, Network Processor Offloading, Session State Indicators section

The output of the diagnose debug rating command is used to view the process by which FortiGate selects the best FortiGuard Distribution Server (FDS). The algorithm primarily uses Round Trip Time (RTT) to rate the servers, preferring the one with the lowest RTT. In the provided exhibit, the output explicitly identifies the chosen server with the line: Server 208.91.112.194, best, RTT 10, T[-5]. This indicates that among the available servers, 208.91.112.194 was selected as the optimal choice.

A. The server 66.117.56.37 is listed, but it is not marked as the 'best' server in the summary output.

C. The server 209.22.147.36 is listed, but it is not marked as the 'best' server in the summary output.

D. The server 64.26.151.37 is listed, but it is not marked as the 'best' server in the summary output.

Fortinet FortiOS 7.6.0 CLI Reference, diagnose debug rating command description, page 319. The documentation explains that this command shows the rating of FortiGuard servers, and the output format includes an indicator for the 'best' server.

Fortinet FortiOS 7.6.0 Administration Guide, "FortiGuard services" section, page 125. It describes how FortiGate communicates with FDS and uses a rating system to ensure it connects to the most responsive server.

The debug output from the SAML daemon (samld) contains the line [samldsendcommonreply:495] IN state=5, type=1, id=1, name=sslvpn. The name=sslvpn parameter explicitly identifies the service or application for which the SAML authentication request is being processed. This indicates that a user is attempting to authenticate for an SSL VPN connection, and the FortiGate (acting as the Service Provider) is handling the SAML exchange with the Identity Provider.

A. The debug shows the IdP is AzureAD. While Azure AD can use Active Directory as a backend, the debug itself does not confirm this; it only confirms the SAML exchange.

C. The IP address 10.1.10.254 is not identified as the IdP in the log. The log shows the IdP is named AzureAD.

D. The IP address 10.1.10.2 is identified as the remote-ip, which is the IP address of the client initiating the SSL VPN connection, not the IdP.

1. FortiOS 7.6.0 Administration Guide, "SAML," Page 689. This section describes configuring SAML for different services, including SSL VPN, and notes that the samld process handles these requests.

2. FortiOS 7.6.0 Troubleshooting Guide, "SAML authentication troubleshooting," Page 590. The guide explains how to use diagnose debug application samld -1 and interpret the output, where service names like sslvpn appear in the logs to identify the authentication context.

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".