Free demo
FCSS_NST_SE-7.6 Free Demo Questions
A sample from the full question set for this exam.
QUESTION 1 OF 5
Consider the scenario where the server name indication (SNI) does not match either the common name (CN) or any of the subject alternative names (SAN) in the server certificate. Which action will FortiGate take when using the default settings for SSL certificate inspection?
Correct Answer: D
When FortiGate performs SSL certificate inspection with default settings, it checks if the Server Name Indication (SNI) matches either the Common Name (CN) or any Subject Alternative Name (SAN) in the server certificate. If there is no match, FortiGate does not block the connection; instead, it uses the CN value from the certificate's subject field to continue web filtering and categorization.
This behavior is described in the official Fortinet 7.6.4 Administration Guide:
“Check the SNI in the hello message with the CN or SAN field in the returned server certificate: Enable: If it is mismatched, use the CN in the server certificate.” This is the default (Enable) mode, which differs from the Strict mode that would block the mismatched connection.
By default, this policy ensures service continuity and prevents disruptions due to certificate mismatches, allowing FortiGate to log and inspect based on the CN even when the requested SNI does not match. It provides a balance between connection reliability and the accuracy of filtering by certificate identity, allowing security policies to remain functional without unnecessary blocks. This approach is recommended by Fortinet to maintain usability for end-users while still supporting granular inspection.
This behavior is described in the official Fortinet 7.6.4 Administration Guide:
“Check the SNI in the hello message with the CN or SAN field in the returned server certificate: Enable: If it is mismatched, use the CN in the server certificate.” This is the default (Enable) mode, which differs from the Strict mode that would block the mismatched connection.
By default, this policy ensures service continuity and prevents disruptions due to certificate mismatches, allowing FortiGate to log and inspect based on the CN even when the requested SNI does not match. It provides a balance between connection reliability and the accuracy of filtering by certificate identity, allowing security policies to remain functional without unnecessary blocks. This approach is recommended by Fortinet to maintain usability for end-users while still supporting granular inspection.
QUESTION 2 OF 5
Exhibit.
Exhibit.
Refer to the exhibit, which contains partial output from an IKE real-time debug. Which two statements about this debug output are correct? (Choose two.)
Correct Answer: C,D
From the exhibit, you can observe that the debug output captures an IKEv1 negotiation in aggressive mode. Let's break down the supporting details in line with official Fortinet IPsec VPN troubleshooting resources and debug guides:
For Option B:
The very first line of the debug output shows:
comes 10.0.0.2:500->10.0.0.1:500, ifindex=7.
This indicates the traffic direction—from the remote IP (10.0.0.2) with port 500 to the local IP (10.0.0.1) with port 500. According to Fortinet's documentation, the right side of the arrow always represents the
local FortiGate gateway. Thus, 10.0.0.1 is the local gateway IP address.
For Option D:
You see the statement:
negotiation result "remote" and
received peer identifier FQDNCE88525E7DE7F00D6C2D3C00000000
Official debug documentation describes that the "peer identifier" or peer ID sent by the initiator is displayed here. In the context of IKE/IPsec negotiation, this value is used as the IPsec peer ID for authentication and identification purposes. The initiator is providing "remote" as the peer ID for its connection.
Why Not A or C:
Perfect Forward Secrecy (PFS): The debug does not show any DH group negotiation in phase 2 (no reference to group2, group5, etc., for phase 2), so you cannot deduce the presence of PFS solely from this output.
Phase 2 negotiation: The log focuses on IKE (phase 1) negotiation and establishment; there’s no reference to ESP protocol, Quick Mode, or other identifiers that would show phase 2 SA negotiation and establishment.
This interpretation aligns with the explanation in the FortiOS 7.6.4 Administration Guide's VPN section and the official debug command output samples published in Fortinet’s documentation. It demonstrates how to distinguish between local and remote addresses and how to identify the use of peer IDs.
For Option B:
The very first line of the debug output shows:
comes 10.0.0.2:500->10.0.0.1:500, ifindex=7.
This indicates the traffic direction—from the remote IP (10.0.0.2) with port 500 to the local IP (10.0.0.1) with port 500. According to Fortinet's documentation, the right side of the arrow always represents the
local FortiGate gateway. Thus, 10.0.0.1 is the local gateway IP address.
For Option D:
You see the statement:
negotiation result "remote" and
received peer identifier FQDNCE88525E7DE7F00D6C2D3C00000000
Official debug documentation describes that the "peer identifier" or peer ID sent by the initiator is displayed here. In the context of IKE/IPsec negotiation, this value is used as the IPsec peer ID for authentication and identification purposes. The initiator is providing "remote" as the peer ID for its connection.
Why Not A or C:
Perfect Forward Secrecy (PFS): The debug does not show any DH group negotiation in phase 2 (no reference to group2, group5, etc., for phase 2), so you cannot deduce the presence of PFS solely from this output.
Phase 2 negotiation: The log focuses on IKE (phase 1) negotiation and establishment; there’s no reference to ESP protocol, Quick Mode, or other identifiers that would show phase 2 SA negotiation and establishment.
This interpretation aligns with the explanation in the FortiOS 7.6.4 Administration Guide's VPN section and the official debug command output samples published in Fortinet’s documentation. It demonstrates how to distinguish between local and remote addresses and how to identify the use of peer IDs.
QUESTION 3 OF 5
Exhibit.
Exhibit.
Refer to the exhibit, which shows the output of a diagnose command. What can you conclude about the debug output in this scenario?
Correct Answer: C
The exhibit displays the output from the diagnose debug rating command on a FortiGate device. This command is used to display information about FortiGuard Web Filtering or other security-related queries performed by FortiGate to FortiGuard servers. Official Fortinet documentation outlines the meaning of each field in the server list. The FortiGate maintains a list of available FortiGuard servers, selecting the optimal server based on factors such as weight, round-trip time (RTT), and regional settings.
The very first entry in the server list after "Server List" is the server FortiGate initially uses, prioritized by factors such as proximity and RTT. Here, 64.26.151.37 is listed first, and the FortiGuard-requests value confirms that this server handled the highest number of requests.
The IPs, weights, and lost/failed counters are monitored for server performance and selection over time.
FortiGate's default operational logic is to try the first entry for contract validation and use the next in the list if the first is unavailable or has high latency or packet loss.
There is no direct correlation between the Weight and the number of FortiGuard-requests. The servers with higher or lower weights may still handle different request volumes based on availability and performance.
The TZ (time zone) value's sign (positive or negative) does not affect server preference; it is informational, showing the server's location relative to UTC, not a rating metric.
DNS query results for FortiGuard servers are not shown here, and the provided servers are not returned in DNS query order.
This command and interpretation are detailed in the FortiOS Administration Guide’s section describing FortiGuard server selection and contract validation processes.
The very first entry in the server list after "Server List" is the server FortiGate initially uses, prioritized by factors such as proximity and RTT. Here, 64.26.151.37 is listed first, and the FortiGuard-requests value confirms that this server handled the highest number of requests.
The IPs, weights, and lost/failed counters are monitored for server performance and selection over time.
FortiGate's default operational logic is to try the first entry for contract validation and use the next in the list if the first is unavailable or has high latency or packet loss.
There is no direct correlation between the Weight and the number of FortiGuard-requests. The servers with higher or lower weights may still handle different request volumes based on availability and performance.
The TZ (time zone) value's sign (positive or negative) does not affect server preference; it is informational, showing the server's location relative to UTC, not a rating metric.
DNS query results for FortiGuard servers are not shown here, and the provided servers are not returned in DNS query order.
This command and interpretation are detailed in the FortiOS Administration Guide’s section describing FortiGuard server selection and contract validation processes.
QUESTION 4 OF 5
Refer to the exhibit, which shows the output of a policy route table entry.
Refer to the exhibit, which shows the output of a policy route table entry.
Which type of policy route does the output show?
Correct Answer: A
The exhibit for question 4 shows a policy route table entry, and key fields are as follows: internet service(1) : Fortinet-FortiGuard(1245324,0.0.0.0,0.0.0.0)
According to the Fortinet official documentation, when a policy route is based on Internet Service Database (ISDB) entries, the route entry will specifically mention “internet service,” showing the service being referenced (in this example, Fortinet-FortiGuard). This is fundamentally different from a regular policy route, which is defined by source, destination, and service wildcards without referencing an ISDB signature. A regular policy route's output would not contain the line “internet service.”
Policy routes that use ISDB allow FortiGate to steer traffic for specific well-known services (like FortiGuard, Google, Microsoft) based on traffic pattern recognition, even if the destination IP is dynamic. The matching and route selection follow the ISDB tag and can coexist with static or regular policy routes.
Thus, this entry is correctly and uniquely an ISDB route, as explained in the FortiOS policy routing documentation and ISDB configuration references.
According to the Fortinet official documentation, when a policy route is based on Internet Service Database (ISDB) entries, the route entry will specifically mention “internet service,” showing the service being referenced (in this example, Fortinet-FortiGuard). This is fundamentally different from a regular policy route, which is defined by source, destination, and service wildcards without referencing an ISDB signature. A regular policy route's output would not contain the line “internet service.”
Policy routes that use ISDB allow FortiGate to steer traffic for specific well-known services (like FortiGuard, Google, Microsoft) based on traffic pattern recognition, even if the destination IP is dynamic. The matching and route selection follow the ISDB tag and can coexist with static or regular policy routes.
Thus, this entry is correctly and uniquely an ISDB route, as explained in the FortiOS policy routing documentation and ISDB configuration references.
QUESTION 5 OF 5
Exhibit.
Exhibit.
Refer to the exhibit, which shows a FortiGate configuration.
An administrator is troubleshooting a web filter issue on FortiGate. The administrator has configured a web filter profile and applied it to a policy; however the web filter is not inspecting any traffic that is passing through the policy.
What must the administrator do to fix the issue?
Correct Answer: A
The exhibit shows a FortiGate configuration under config system fortiguard related to web filtering and FortiGuard options. There is a line:
set webfilter-force-off enable
According to official Fortinet documentation, the "webfilter-force-off" option, when enabled, causes the FortiGate to bypass web filtering for all traffic—even if a web filter profile is applied to a policy.
This override is typically used for troubleshooting or performance reasons and is documented as an explicit bypass feature.
If an administrator wants to enforce web filtering inspection, this setting must be disabled. The correct way to restore web filtering functionality is to run:
set webfilter-force-off disable
Once done, traffic passing through policies with web filter profiles will be inspected and filtered as per configuration. Other settings such as timeout or cache TTL do not bypass web filtering; they only affect operational nuances.
set webfilter-force-off enable
According to official Fortinet documentation, the "webfilter-force-off" option, when enabled, causes the FortiGate to bypass web filtering for all traffic—even if a web filter profile is applied to a policy.
This override is typically used for troubleshooting or performance reasons and is documented as an explicit bypass feature.
If an administrator wants to enforce web filtering inspection, this setting must be disabled. The correct way to restore web filtering functionality is to run:
set webfilter-force-off disable
Once done, traffic passing through policies with web filter profiles will be inspected and filtered as per configuration. Other settings such as timeout or cache TTL do not bypass web filtering; they only affect operational nuances.
Question 1 of 5