The Fortinet NSE 4 - FortiOS 7.6 Administrator (NSE4_FGT_AD-7.6)

From the HA configuration shown for HQ-NGFW-1:

set memory-based-failover enable

set memory-failover-threshold 70

set memory-failover-monitor-period 50

set memory-failover-sample-rate 10

set memory-failover-flip-timeout 60

set override disable

set priority 200

From the performance status outputs:

HQ-NGFW-1 memory used is 90% (well above the configured threshold of 70%)

HQ-NGFW-2 memory used is about 48.7% (well below the threshold)

What happens in FortiOS 7.6 with memory-based failover

When memory-based failover is enabled, FortiGate monitors memory utilization. If the unit’s memory usage stays above the configured memory-failover-threshold for the configured memory-failover-monitor-period, the cluster triggers a failover away from the unit under memory pressure.

Threshold = 70%

HQ-NGFW-1 is at 90%, so it violates the threshold.

Monitor period = 50 seconds.

The administrator observed for 55 seconds, which is longer than 50 seconds, so the condition is met for long enough to trigger failover.

The memory-failover-flip-timeout 60 is used to prevent rapid back-and-forth role changes (flapping) after a failover decision; it does not prevent the initial failover from occurring once the threshold breach persists for the monitor period.

The exhibit shows the output of the following command:

diagnose test application ipsmonitor 1

pid = 2044, engine count = 0 (+1)

0 - pid:2074:2074 cfg:1 master:0 run:1

How to interpret this output (FortiOS 7.6 – IPS internals)

ipsmonitor displays the status of IPS engines running on the FortiGate.

engine count = 0 means:

No IPS scanning engines are currently active

IPS is not processing any traffic

In FortiOS, IPS engines are started on demand.

Critical documented behavior

IPS processes are only spawned when at least one firewall policy is configured with an IPS profile and traffic matches that policy.

If no firewall policy references an IPS profile, the IPS engine:

Does not start

Shows engine count = 0

Appears “not working,” even though the IPS profile exists

This is exactly what the diagnose output indicates.

Why option A is correct

A. There is no firewall policy configured with an IPS security profile.

Creating an IPS profile alone is not sufficient

IPS must be applied to an active firewall policy

Traffic must match that policy for the IPS engine to run

Otherwise, ipsmonitor will show engine count = 0

This matches FortiOS 7.6 IPS operational behavior.

Why the other options are incorrect

B. Administrator entered the command diagnose test application ipsmonitor 5.

Incorrect.

The exhibit clearly shows ipsmonitor 1

Using a different argument would not explain engine count = 0

C. FortiGate entered into IPS fail open state.

Incorrect.

In fail-open, IPS engines may be bypassed, but they still initialize

engine count = 0 specifically indicates IPS is not in use at all

D. Administrator entered the command diagnose test application ipsmonitor 99.

Incorrect.

The command argument affects debug level, not engine creation

Again, the exhibit shows ipsmonitor 1

In FortiOS 7.6, when multiple dialup IPsec VPNs are configured on the same FortiGate—especially in Aggressive Mode—FortiGate must identify which Phase 1 configuration a connecting client should match.

How FortiGate selects a dialup IPsec tunnel

For dialup VPNs:

The remote peer (user or device) does not have a fixed IP address

Multiple Phase 1 interfaces may exist on the HQ FortiGate

FortiGate uses identifying information sent during IKE Phase 1 to select the correct tunnel

Aggressive Mode behavior

Aggressive mode sends ID information in clear text during Phase 1

This allows FortiGate to match incoming peers to the correct Phase 1 configuration

Why Peer ID is the correct answer

C. Peer ID

Peer ID (also called IKE ID) is used to:

Identify the remote peer

Differentiate between multiple dialup tunnels

Common Peer ID formats:

FQDN

User FQDN

Key ID

FortiGate matches the received Peer ID against the Phase 1 configuration to select the correct tunnel

This is the documented and recommended method for:

Mapping users to different department tunnels

Supporting multiple dialup IPsec VPNs in aggressive mode

Why the other options are incorrect

A. Local GatewayIdentifies the local FortiGate interface/IP, not the remote user.

B. Dead Peer DetectionUsed only for tunnel health monitoring, not tunnel selection.

D. IKE Mode ConfigUsed for assigning IP addresses and pushing settings, not for selecting the Phase 1 tunnel.

According to the FortiOS 7.6 Administrator Study Guide, while there is a global administrative idle timeout setting that applies to all users by default (typically 5 minutes), FortiOS allows for granular control through Administrator Profiles . The Override Idle Timeout feature is specifically designed to allow different timeout values for different access profiles, which is ide 1 al for environments like a Network Operations Center (NOC) where persistent monitoring is required. 23

To implement this, the administrator must modify the s 4 pecific access profile settings. By using the command config system accprofile 5 and editing the NOC_Access profile, the administrator can enable the admintimeout-override and then increase the admintimeout value (Statement D). This configuration ensures that only the users assigned to that specific profile benefit from the extended session duration, maintaining a higher security posture for other administrative accounts that still follow the global timeout. Other options, such as changing the profile order (A) or assigning the super_admin role (C), do not address the specific requirement for inactivity timeout management. Option B is incorrect as " offline value " is not a standard parameter for this feature.

Comprehensive and Detailed 150 to 200 words of Explanation From Exact Extract of FortiOS 7.6 documents:

According to the FortiOS 7.6 Administration Guide, the firewall policy ID is a unique numerical identifier assigned to each policy for internal database tracking and management purposes. It is important to distinguish the policy ID from the policy sequence . While the FortiGate processes traffic based on a top-down approach (the sequence), the policy ID itself does not determine the order of execution (Statement A is incorrect).

In FortiOS, once a policy is committed to the configuration, the policy ID cannot be modified (Statement B). If an administrator needs to change a policy ID, they must either delete and recreate the policy or use the clone command in the CLI to copy the settings to a new ID.

Furthermore, the CLI provides a specific shortcut for policy creation: you can create a policy with ID 0 (Statement C). When the command edit 0 is used within the config firewall policy context, the FortiOS kernel automatically assigns the next available integer as the policy ID. This is a standard practice for efficient configuration via the command line. Statement D is incorrect because, while every policy must have an ID, the GUI automatically generates this value without requiring the user to manually provide or even see it during the initial creation process.

In FortiOS 7.6, GUI session inactivity timeout behavior for administrators is controlled by admin profiles, not by general access permissions or profile ordering.

How GUI idle timeout works in FortiOS 7.6

FortiGate has a global admin timeout (admintimeout), but

Admin profiles can override this value using the Override idle timeout setting.

When Override idle timeout is enabled in an admin profile, the timeout value defined inside that profile takes precedence over the global setting.

The exhibit shows that the NOC team logs in using the NOC_Access admin profile. Therefore, to prevent their GUI sessions from disconnecting too quickly during inactivity, the timeout must be adjusted within that specific admin profile.

Why option B is correct

B. Increase the value of the Override Idle Timeout parameter in the NOC_Access admin profile.

This directly controls how long GUI sessions remain active when users assigned to NOC_Access are idle.

It affects only the NOC team, which matches the requirement precisely.

This is the recommended and documented approach in FortiOS 7.6.

Why the other options are incorrect

A. Increase admintimeout under config system accprofileIncorrect. admintimeout is a global admin setting, not configured under accprofile, and it would affect all administrators, not just NOC users.

C. Move NOC_Access to the top of the listIncorrect. Admin profile order has no impact on session timeout behavior.

D. Assign super_admin roleIncorrect and insecure. Super_admin does not control idle timeout and would unnecessarily grant full privileges.

From the current HA status, HQ-NGFW-1 is the primary and HQ-NGFW-2 is the secondary.

The administrator then changes these HA parameters:

HQ-NGFW-1: set override disable, set priority 90

HQ-NGFW-2: set override enable, set priority 110

In FGCP (A-P mode), the override (preemption) feature controls whether a higher-priority unit is allowed to take over the primary role.

When override is enabled, the cluster will prefer (and can re-elect) the unit with the highest device priority to become primary (preempting a lower-priority primary when conditions trigger re-election behavior as defined by FGCP).

Here, HQ-NGFW-2 has:

override enabled

higher priority (110) than HQ-NGFW-1 (90)

Therefore, the expected result is that HQ-NGFW-2 becomes the primary.

Why the other options are incorrect:

B is incorrect because it claims HQ-NGFW-2 has lower priority (it is higher: 110 > 90).

C is incorrect because a mismatch in the override setting is not what causes the “configuration out of sync” condition shown in get system ha status (that is about synchronized configuration databases, not a requirement that override values must match to remain in-sync).

D is incorrect because HA settings like override/priority are not synchronized in the way regular configuration objects are; they are device-level HA parameters.

According to the FortiOS 7.6 Administrator Guide and the specific behavior of the SD-WAN GUI, here is the technical breakdown:

SD-WAN Zone Hierarchy and UI Elements: In the FortiGate GUI, SD-WAN zones that contain member interfaces are displayed with a plus (+) icon next to the checkbox. This icon allows administrators to expand the zone and view the specific physical or logical interfaces assigned to it.

Analysis of the " Underlay " Zone: In the provided exhibit, the virtual-wan-link and overlay zones both feature the plus (+) expansion icon, indicating they have active members. The Underlay zone, however, lacks this icon and displays a red status icon. This is the visual indicator in FortiOS that the zone is currently empty and contains no member interfaces.

Mandatory Zone Membership: In FortiOS 7.x, every SD-WAN member interface must be assigned to a zone. It is not possible for an interface to be an " SD-WAN member " (as shown in the legend with port2 and port3) without being assigned to a zone. Since port2 and port3 are listed in the legend, they are indeed assigned to one of the other expanded zones (likely virtual-wan-link or overlay), making Option D incorrect.

Default Zone Behavior: While FortiOS 7.6 often creates default zones like virtual-wan-link, underlay, and overlay during certain configuration wizards or by default in newer versions, they are distinct entities. There is no single " default " zone that acts as a global catch-all in the way Option C suggests.

Immutability of System Zones: While certain system-defined zones have restrictions, the primary focus of this specific exhibit is the current membership state, which clearly shows the Underlay zone is empty.

Phase 1 being up confirms the two FortiGate devices can authenticate and build the IKE SA. Phase 2 failing indicates the IPsec (Quick Mode) SA negotiation is failing due to mismatched Phase 2 parameters.

From the exhibit, the Phase 2 mismatches that would prevent SA establishment are:

1) Phase 2 selectors must mirror each other (Proxy IDs)

HQ-NGFW Phase 2 selector shows:

Local: 10.0.11.0/24

Remote: 172.20.1.0/24

BR1-FGT Phase 2 selector shows:

Local: 172.20.1.0/24

Remote: 10.11.0.0/24 ⟵ does not match HQ’s local subnet (10.0.11.0/24)

In FortiOS, Phase 2 comes up only when the peers’ selectors (proxy IDs) match as opposite pairs (local on one side = remote on the other).

✅ Fix: A. On BR1-FGT, set Remote Address to 10.0.11.0/255.255.255.0.

2) Phase 2 proposal must match (encryption/authentication)

HQ-NGFW shows encryption AES128 (with SHA1)

BR1-FGT shows encryption AES256 (with SHA1)

For Phase 2 to establish, both peers must have at least one common proposal (same encryption and authentication settings). With one side set to AES128 and the other to AES256, there is no match.

✅ Fix: D. On HQ-NGFW, set Encryption to AES256.

Why the other options are not correct

B. Enable Diffie-Hellman Group 2: The exhibit’s mismatch is not resolved by adding DH group 2, and DH group must match when PFS is enabled. This option does not align the peers based on what’s shown.

C. Set Seconds to 43200: Phase 2 lifetime mismatches typically do not prevent Phase 2 from coming up (the negotiated lifetime can be adjusted by the peers). The hard blockers here are the selectors and proposal mismatch.