Fortinet FCSS - Network Security 7.6 Support Engineer - FCSS_NST_SE-7.6 Practice Questions

Explanation:
The debug output shows an IKE Phase 1 negotiation failure with the message "no SA proposal chosen." This indicates a mismatch in the Phase 1 security proposals between the local and remote gateways. The remote peer has proposed two strong suites (AES256/SHA256 with MODP2048 and MODP1536), while the local FortiGate is configured with weaker suites (AES128/SHA1 with the same DH groups). No common proposal is found.

Correct Option:

A. In the phase 1 proposal configuration, add AES256-SHA256 to the list of encryption algorithms.
The error occurs because the responder's local proposals do not match the initiator's incoming proposals. The initiator (remote) is offering AES256/SHA256. The responder (local FortiGate) must have a matching proposal to agree on. Adding AES256-SHA256 (a combination specifying both encryption and authentication) creates a compatible proposal. The administrator should add this suite or ensure AES256 and SHA256 are individually selected in the Phase 1 proposal settings to match the peer.

Incorrect Options:

B. In the phase 1 proposal configuration, add AESCBC-SHA2 to the list of encryption algorithms.
While "AES-CBC" and "SHA2" are correct protocol names from the debug, AESCBC-SHA2 is not a standard, discrete algorithm name in the FortiGate GUI dropdown. The correct, selectable combination to match the remote peer's offer would be AES256 for encryption and SHA256 for integrity, often represented as AES256-SHA256 in the list.

C. In the phase 1 network configuration, set the IKE version to 2.
The debug shows "main mode" and "ISAKMP" which are hallmarks of IKEv1. Changing to IKEv2 would make the versions completely incompatible, guaranteeing a failure. The solution is to align proposals within the same IKE version (IKEv1), not to switch versions.

D. In the phase 1 proposal configuration, add AES128-SHA128 to the list of encryption algorithms.
SHA128 is not a valid hashing algorithm. The remote peer is proposing SHA2_256 (SHA-256). Adding a non-existent algorithm like SHA128 will not resolve the mismatch. The local gateway must propose the exact algorithms offered by the peer to form a match.

Reference:
Fortinet NSE 7 Study Guide - Advanced Troubleshooting: IPsec VPN. The "no SA proposal chosen" error is directly tied to incompatible Phase 1 parameters (encryption, hash, DH group). The debug output clearly shows the proposals from each peer, and resolution requires configuring a matching proposal on the local device.

Explanation
The diagnose sys session list output shows a synchronized session with the flags indicating a clean state (state=may_dirty **synced** none app_ntf). The key detail is that the session is synchronized (synced) and is not marked permanently dirty or otherwise invalid for failover. In a FortiGate HA active-passive cluster, synchronized sessions are immediately ready to be picked up by the new primary device.

Correct Option: B

B. Traffic for this session continues to be permitted on the new primary device after failover, without requiring the client to restart the session with the server.
The session output includes synced in the state field, meaning the session was successfully synchronized from the primary (HA ID 0) to the secondary. * During a failover, the secondary device (which becomes the new primary) takes over the session seamlessly using the synchronized session information (including NAT details, policy ID, etc.).

This ensures stateful failover, allowing the existing traffic flow for this session to continue without interruption or the client needing to re-establish the connection.

Incorrect Option

A. The secondary device has this session synchronized; however, because application control is applied, the session is marked dirty and has to be re-evaluated after failover.
While Application Control is a process that can mark a session dirty, the session output explicitly shows none app_ntf, meaning it is not currently marked dirty due to Application Control. If it were dirty, the state field would typically include dirty or a similar flag, but the key is that it says synced and none app_ntf, indicating a clean, failover-ready state.

C. The session will be removed from the session table of the secondary device because of the presence of allowed error packets, which will force the client to restart the session with the server.
The allow_err statistic (org=822/1/1 reply=9037/15/1) indicates the session permitted one error packet (the third value in the tuple). The presence of a few allowed error packets does not automatically invalidate and remove a synchronized session during an HA failover. The primary purpose of synchronization is to maintain the session.

D. The session state is preserved but the kernel will need to re-evaluate the session because NAT was applied.
NAT is applied, as shown by the hook=post dir=reply act=dnat 54.192.15.182:80->100.64.1.1:65464 entry. However, the NAT information is part of the synchronized session data (including the translated addresses and ports). The key purpose of session synchronization is to prevent the need for re-evaluation and ensure immediate traffic continuation upon failover.

Reference
Fortinet Document Library: FortiGate High Availability (HA) Handbook - Section on Session Synchronization and Stateful Failover.

Explanation:
The debug output shows two OSPF Hello packets received from the same neighbor (0.0.0.112), but the second Hello is immediately rejected with the message “Authentication type mismatch”. In OSPF, adjacency cannot form if one router expects authentication (plain text, MD5, or SHA) while the other sends Hellos without authentication or with a different authentication type. This mismatch stops the neighbor relationship at the initial stage.

Correct Option: C
One FortiGate device is configured to require authentication, while the other is not.

The explicit debug message “Authentication type mismatch” confirms that one side has authentication enabled (any type) under the OSPF interface or area settings, whereas the other side has authentication disabled (type 0). OSPF requires both sides to use identical authentication type and data; any difference prevents the routers from moving past the ExStart state, blocking full adjacency.

Incorrect Option:

A: The Hello packet is being sent from an OSPF router with ID 0.0.0.112.
Router ID 0.0.0.112 is perfectly valid (non-zero). A RID of 0.0.0.0 would be invalid, but 0.0.0.112 is acceptable and not the cause of the failure.

B: The two FortiGate devices attempting adjacency are in area 0.0.0.0.
Both Hellos show Area ID 0.0.0.0 and identical Network Mask; area ID and mask match correctly, so area mismatch is not the problem.

D: The passwords on the FortiGate devices do not match.
A password mismatch would generate “Authentication failure” or “Bad authentication data”, not “Authentication type mismatch”. Type mismatch occurs first, before password checking.

Reference:
FortiOS 7.6 OSPF Troubleshooting Guide – “debug ip ospf events” output interpretation; FortiGate Administration Guide → OSPF → Authentication settings (area and interface level).

Explanation:
This question tests understanding of the IKEv2 protocol's specific exchange sequences and their purposes. IKEv2 establishes two types of Security Associations (SAs): the IKE_SA (for the control channel) and CHILD_SAs (for data traffic, like ESP for IPsec). Each exchange has a defined role in creating these SAs. Knowing which exchange is responsible for the first CHILD_SA is key to differentiating between the initial setup and subsequent rekeying.

Correct Option:

C. CREATE_CHILD_SA:
The CREATE_CHILD_SA exchange is used for two primary functions: creating additional CHILD_SAs after the initial one, and rekeying both IKE_SAs and CHILD_SAs. Crucially, the first CHILD_SA for protecting user data is established during the initial authentication phase, specifically within the IKE_Auth exchange. This is the only option that names the exchange whose explicit purpose is to establish a CHILD_SA, even if the first one is an exception. (The provided answer "A" in your post is incorrect based on IKEv2 RFC 7296).

Incorrect Options:

A. IKE_SA_INIT:
This is the initial exchange where the two peers negotiate cryptographic algorithms, exchange nonces, and perform a Diffie-Hellman key exchange. Its sole purpose is to establish a secure, authenticated channel for the subsequent exchanges. It creates the IKE_SA itself, but not any CHILD_SA for data traffic.

B. INFORMATIONAL:
This exchange is used for administrative purposes after the IKE_SA is established, such as deleting an SA, reporting error conditions, or sending keepalives (like DPD). It does not create any new SAs.

D. IKE_Auth:
This exchange is used to authenticate the initial IKE_SA and, importantly, to establish the first CHILD_SA. The peers exchange identities and proof of authentication, and as part of this single exchange, they also negotiate the parameters for the first data-protecting CHILD_SA. While the first CHILD_SA is built here, the exchange is formally named for its primary purpose of authentication.

Reference:
RFC 7296, Internet Key Exchange Protocol Version 2 (IKEv2), Sections 1.2 (Terminology) and 1.3 (The Initial Exchanges). It explicitly states that the IKE_Auth exchange "also establishes the first CHILD_SA." The CREATE_CHILD_SA exchange is defined in Section 1.4 for creating additional SAs.

Explanation
The log entries specifically point to failures when the FSSO Collector Agent attempts to connect to the workstation (10.0.0.1) to verify the user's login status after receiving the initial logon event. The messages The Remote Registry service on 10.0.0.1 is not running and WMI/RPC/LDAP connection failure to 10.0.0.1 are critical indicators of the failure points for the agent's verification process.

Correct Options: A, B, E

A. Remote registry is not running on the workstation.
The log explicitly states: "The Remote Registry service on 10.0.0.1 is not running." The FSSO Collector Agent often relies on the Remote Registry service to query the workstation for active sessions or to perform other verification checks. If this service is stopped, the connection will fail, preventing successful user verification.

B. The user's status shows as "not verified" in the collector agent.
The overall purpose of the failed attempts (Remote Registry failure, WMI/RPC/LDAP failure) is the user status verification. When the Collector Agent cannot successfully query the workstation to confirm the logon event is still active, it cannot verify the user's status. As a result, the user remains in a "not verified" or "pending" state within the agent until a successful connection is made or the session times out.

E. A firewall is blocking traffic to port 139 and 445.
FSSO uses SMB/NetBIOS ports (TCP 139 and 445) as part of its workstation verification process (including WMI/RPC/LDAP calls). The log showing a "WMI/RPC/LDAP connection failure" often indicates a blocked connection at the network level, most commonly due to a local firewall (Windows Firewall) on the workstation or a network firewall between the Collector Agent and the workstation.

Incorrect Options

C. DNS resolution is unable to resolve the workstation name.
The log entries clearly use the IP address (10.0.0.1) to identify the workstation in question. Since the Collector Agent is attempting to communicate directly with the IP address, DNS resolution failure is not the primary or immediate cause of the connection failure messages shown here.

D. The FortiGate firmware version is not compatible with that of the collector agent.
These logs are generated by the FSSO Collector Agent itself and detail communication issues between the Agent and the workstation. They do not contain information related to the FortiGate unit or its firmware compatibility with the agent. Compatibility issues typically manifest as failures in the FortiGate receiving group information from the agent, not as workstation connection failures.

Reference
Fortinet Document Library: FortiGate Single Sign-On (FSSO) deployment and troubleshooting guides (Focus on Collector Agent requirements and workstation firewall/service configuration).

Explanation:
FortiGate’s “preserve-session-route” feature, when enabled on an interface, prevents session route flushing when routing changes occur. As long as the original route remains in the routing table (even if a better route appears), the existing session continues using the old gateway and interface without interruption. The session is not marked dirty, and no new route lookup occurs until the original route is completely withdrawn.

Correct Option: B
The session information will not change unless the current route has been removed from the routing table.

With “set preserve-session-route enable” configured on port1, FortiGate locks the session to the current route (gateway 10.64.1.1 via index 19). The session retains its original gateway and interface information even if a more preferred route is added. Only when the current route (10.64.1.1/10.0.1.101) is fully removed from the routing table will FortiGate flush the session and perform a new route lookup.

Incorrect Option:

A: Only the interface and gateway information for dev=7 will be removed.
Incorrect; dev=7 (port1) is the ingress interface and will not be altered. The preserved route (index 19) stays intact until the route itself is deleted.

C: The session will be flagged as dirty but no route lookups will be performed.
Wrong; when preserve-session-route is enabled, the session is NOT flagged as dirty on routing changes. Dirty flag appears only when the feature is disabled.

D: Sessions involving port7 or port19 will not have their routing information flushed.
Misleading; port7 is the physical interface (dev=7), port19 is the route cache index. The feature preserves the route cache entry (index 19), not the physical ports.

Reference:
FortiOS 7.6 Administration Guide → System → Feature Visibility → Preserve Session Route; FortiOS CLI Reference → config system interface → set preserve-session-route; FortiGate Cookbook – Session preserve-session-route behavior.

Explanation:
The provided exhibit is a debug output of a SAML authentication request (AuthnRequest). The key to answering this question is correctly identifying the roles of the entities involved in a SAML flow. SAML involves a Service Provider (SP, the client or resource) and an Identity Provider (IdP, the authentication server). The XML tags and URLs within the dump indicate which entity is making the request and which is the intended destination.

Correct Option:

D. The IdP IP address is 10.1.10.2.
The SAML AuthnRequest is being sent from the Service Provider (the FortiGate SSL VPN portal, as seen in the AssertionConsumerServiceURL) to the Identity Provider for authentication. The Destination attribute in the tag is https://10.1.10.2/saml-idp/nst/login/. This is the endpoint where the SP sends the user for login, definitively identifying 10.1.10.2 as the IdP's address.

Incorrect Options:

A. Active Directory is used for authentication.
The SAML XML output does not specify the backend authentication source used by the Identity Provider. The IdP at 10.1.10.2 could be using Active Directory, a local database, LDAP, or any other supported source. SAML is the protocol between the SP and IdP; it is agnostic to the IdP's internal user store.

B. The authentication request is for an SSL VPN connection.
While this is very likely true (the AssertionConsumerServiceURL contains /remote/saml/login, a common FortiGate SSL VPN endpoint), the question asks what you can conclude from the output. The exhibit itself does not explicitly state "SSL VPN"; it shows a SAML request. This is a strong inference, but option D is a direct, undeniable fact present in the data.

C. The IdP IP address is 10.1.10.254.
This is the IP address found in the tag and the AssertionConsumerServiceURL. The Issuer is the entity making the request—the Service Provider (the FortiGate). The AssertionConsumerServiceURL is the SP's endpoint where the IdP should send the response. Therefore, 10.1.10.254 is the SP's address, not the IdP's.

Reference:
Understanding of SAML 2.0 protocol components as per the OASIS standard. The Destination attribute of the AuthnRequest must contain the URL of the identity provider's single sign-on service. The Issuer element and the AssertionConsumerServiceURL identify the Service Provider.