Fortinet FCSS_NST_SE-7.6 - Fortinet NSE 6 - Network Security 7.6 Support Engineer

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.

To determine why sessions are being removed, we must interpret the specific counters in the diagnose sys session stat output provided in the exhibit.

Analyze memory_tension_drop (Reason A):

Observation: The output shows memory_tension_drop=4.

This counter specifically increments when the FortiGate kernel attempts to allocate a new memory page for a session but fails due to a lack of available system memory. As a result, the session creation is aborted or an existing session is dropped to free up resources. This confirms that the kernel is struggling to allocate memory pages.

Analyze extreme_low_mem (Reason D):

Observation: The output shows extreme_low_mem=0 (which is good), but we must look at the context of memory_tension_drop.

Context: While the extreme_low_mem counter itself is 0 in this snapshot, the presence of memory_tension_drop indicates the system is under memory pressure. Furthermore, in many Fortinet exam contexts involving this specific exhibit, the focus is on the mechanism of "flushing sessions" to recover memory.

Refinement: Actually, look closer at the exhibit. It shows flush=787.

The flush counter indicates the number of times the system has actively purged (flushed) old or stale sessions from the table to recover memory or due to policy changes. A high flush count combined with memory tension drops strongly suggests the system is aggressively removing sessions to handle high memory usage. Therefore, "FortiGate is flushing sessions because of high memory usage" is the correct interpretation of the flush and memory_tension_drop counters working together.

Why other options are incorrect:

B: There is no counter in this specific output (like tcp_syn_sent drop) that indicates dropping incomplete handshakes. The clash=0 and delete=0 counters are low/zero.

C: The dev_down=16/120 field does not mean the device was down for 10 seconds. It refers to device index pointers or internal kernel interface states, not system uptime/downtime impacting session acceptance in the way described.

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.

To determine the behavior, we must analyze the memory thresholds and the current status shown in the exhibit:

Analyze the Thresholds (The Three States):

Green (Exit): 82% (Memory usage is safe).

Red (Enter Conserve Mode): 88% (Memory usage is high; action is required).

Extreme (Kernel Conserve Mode): 95% (Memory is critical; drastic action is required).

Determine the Current State:

Current Memory Used: 89%.

Since 89% is greater than the Red threshold (88%) but lower than the Extreme threshold (95%), the FortiGate is in Red Conserve Mode (User-space conserve mode), not Extreme mode.

Evaluate the Behavior in "Red" Mode:

In Red Conserve Mode, the FortiGate's primary goal is to prevent memory exhaustion while still processing traffic if possible.

Proxy-based inspection (handled by the WAD process) is memory-intensive because it buffers content. To save memory, the system stops accepting new sessions that require proxy-based inspection.

Flow-based inspection (handled by the IPS engine) streams data and consumes significantly less memory. Therefore, in Red mode, the system typically continues to allow and inspect flow-based sessions.

Option A correctly describes this split behavior: allowing flow-based (lighter) but blocking proxy-based (heavier).

Why other options are incorrect:

B: If memory increases another 6% (89% + 6% = 95%), the device hits the Extreme threshold. At 95%, the kernel begins dropping all new sessions to prevent a system crash. Thus, it will not continue to allow sessions.

C: This describes "Fail-Open" behavior (passing traffic without inspection). While configurable (set av-failopen pass), the default is usually "Fail-Close" (blocking). More importantly, the distinction between flow and proxy availability is the key architectural feature of Red mode.

D: Blocking all new sessions regardless of type is the behavior of Extreme Conserve Mode (95%). Since the device is only at 89%, this drastic measure is not yet active.

The partial output from diagnose hardware sysinfo memory provides details on system RAM allocation. According to Fortinet's technical documentation for memory troubleshooting and Linux memory management (which FortiOS is based on):

MemFree is the portion of physical memory not currently allocated to any running process or kernel function. Thus, 708880 kB is available and can be immediately used by user-space programs or system operations.

Inactive refers to pages in the memory cache that were previously in use for I/O or file system buffering but are now not actively referenced. These pages are retained in memory for quick access if needed again, but can be reclaimed for other memory operations if demand increases. The value 98908 kB here represents currently unused cache pages (inactive pages), ready for repurposing or deletion if the system requires more RAM.

Cached represents the total amount of system memory allocated to cache, which includes both active and inactive cache pages. It does not, by itself, represent I/O cache exclusively, nor does "inactive" mean memory “will never be used” as the kernel can re-purpose inactive pages on demand.