NSE4 High Availability and Diagnostics Practice Question
A FortiGate in an active-active HA cluster is experiencing asymmetric routing. The administrator runs 'diagnose debug flow' on a packet from a client to a server. The flow trace shows the packet is allowed by policy, but the response is dropped. What is the most likely cause?
⚠ Common exam trap
NSE4 often tests HA session synchronization — candidates blame HA mode or routing when the real issue is that session-pickup is disabled, causing the secondary to drop return traffic.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The session synchronization is not enabled between cluster members
In an active-active HA cluster, session synchronization (session-pickup / session-sync) must be enabled so that return traffic arriving on a different cluster member finds the existing session. If sync is disabled, the secondary unit has no session entry and drops the response, producing the asymmetric-routing drop seen in the debug flow.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The TTL of the packet is too low
Why it's wrong here
A packet's TTL is decremented at each L3 hop, but both HA members occupy the same L2/L3 hop from the client's perspective, so a low TTL would not affect only the response direction. A TTL too low would cause the packet to expire and be discarded toward either the destination or back to the source, producing failures in both directions. The one-way response drop is more consistent with a lack of session state on the unit receiving the reply.
- ✗
The HA mode should be changed to active-passive
Why it's wrong here
Switching to active-passive HA would eliminate asymmetric routing because only the active unit processes traffic, but that treats the symptom rather than fixing the underlying configuration issue. The cluster is already running active-active, which can work reliably if session synchronization is properly configured. The root cause here is the missing session sync between members, not the HA mode; changing the mode would degrade performance and avoid addressing the actual misconfiguration.
- ✗
The policy on the secondary unit has a different schedule
Why it's wrong here
A policy schedule difference on the secondary unit would only matter if the secondary evaluates the packet against a new policy after failing a session lookup. Every packet arriving on a cluster member first looks up its session table; when session sync is disabled, the reply packet finds no matching session and is dropped before any schedule check occurs. Even if the schedules match exactly, the same drop would happen, so the policy schedule is not the explanation for an asymmetric response failure.
- ✓
The session synchronization is not enabled between cluster members
Why this is correct
In an active-active HA cluster, traffic for a single connection can egress and ingress through different members, and each member must have a copy of the session table. Without session synchronization, the secondary unit that receives the response has no record of the session created by the primary, so it treats the packet as unsolicited traffic and drops it. Enabling session synchronization (for example with 'set session-sync-dev' or using session pickup on FortiGate) ensures both units share session state and can forward replies correctly.
Quick reference
Asymmetric Encryption Algorithm Comparison
| Algorithm | Key Exchange | Signatures | Equivalent Security Key | Notes |
|---|---|---|---|---|
| RSA-3072 | Yes | Yes | 128-bit | Widely deployed; slow for bulk data |
| ECDSA P-256 | No | Yes | 128-bit | Fast signatures; standard TLS certs |
| ECDH / ECDHE | Yes | No | 128-bit | Perfect forward secrecy in TLS 1.3 |
| DH / DHE | Yes | No | 128-bit (3072-bit key) | Replaced by ECDHE in modern TLS |
| Ed25519 | No | Yes | ~128-bit | SSH keys, modern PKI |
Go deeper
Related to this question
About these practice questions
Courseiva writes every NSE4 question from scratch — 773 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
6 more ways this is tested on NSE4
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. In an active-active HA cluster, the administrator notices that traffic is not being load-balanced evenly across both units. What is the most likely cause?
medium- ✓ A.The load balance method is set to 'none'
- B.The heartbeat interface speed is mismatched
- C.The load balance method is set to 'source-ip' which naturally causes imbalance
- D.The cluster is using active-passive mode
Why A: In an active-active HA cluster, traffic load balancing is controlled by the load balance method. If set to 'none', the cluster does not distribute traffic across units, causing uneven load. The correct method, such as 'source-ip' or 'round-robin', must be configured to achieve balance.
Variation 2. A FortiGate HA cluster is set to active-active mode. The administrator notices that session synchronization is enabled but some sessions are not being synced between cluster units. Which of the following is a likely cause for incomplete session synchronization in active-active mode?
medium- A.The cluster is using unicast heartbeat
- ✓ B.The 'set session-sync-id' is not configured or mismatched between cluster units
- C.The heartbeat interface speed is set to 1 Gbps
- D.The HA override is enabled
Why B: In FortiGate active-active HA, session synchronization between cluster units is scoped by the session-sync-id (also called the session pickup group). If the session-sync-id is not configured or is mismatched across cluster members, sessions are only synced within the same sync group, so many sessions never propagate to peer units. This directly causes incomplete session synchronization even though 'session synchronization' is globally enabled.
Variation 3. In an active-active HA cluster, which of the following must be identical on both FortiGate units?
easy- A.HA priority
- B.Management IP address
- ✓ C.Virtual cluster ID
- D.Hostname
Why C: In an active-active HA cluster, the virtual cluster ID must be identical on both FortiGate units because it defines the cluster group and ensures that only units with the same ID can form an HA cluster. This ID is used in heartbeat packets to verify cluster membership and prevent accidental merging of separate clusters. Without a matching virtual cluster ID, the units will not recognize each other as part of the same HA group.
Variation 4. A company has two FortiGate units in an active-active HA cluster. They want to ensure that sessions initiated from the internet through a virtual IP are synchronized to the peer unit in case of failover. Which HA setting is required?
medium- A.Enable 'set ha-mgmt-status enable' on the WAN interface
- B.Set 'set schedule' to 'round-robin' for the VIP
- C.Configure the same virtual IP on both units
- ✓ D.Enable 'session-pickup' under config system ha
Why D: In a FortiGate active-active HA cluster, session-pickup (also called session synchronization) must be enabled under 'config system ha' to ensure that sessions — including those initiated through a virtual IP from the internet — are synchronized to the peer unit. Without session-pickup, a failover would drop existing sessions because the new primary has no state for them. This is the specific HA setting that controls whether firewall sessions are mirrored across cluster members.
Variation 5. In an active-active HA cluster, what is the purpose of the 'session sync' configuration?
hard- A.To synchronize configuration changes between cluster members
- B.To balance the number of sessions across cluster members
- ✓ C.To replicate session state so that if one unit fails, another can take over without interruption
- D.To synchronize the time between cluster members
Why C: Session sync ensures that sessions are shared between cluster units so that any unit can handle traffic for a given session.
Variation 6. In an active-active HA cluster, session synchronization is configured. A new session is created on the primary unit. When does the secondary unit learn about this session?
hard- A.During the next heartbeat interval
- B.After the session is closed
- ✓ C.Within a few milliseconds to seconds after creation
- D.Immediately upon session creation
Why C: In an active-active HA cluster, FortiGate performs real-time session synchronization (session-pickup) between cluster members over the HA heartbeat link. When a new session is created on the primary, the session table entry is pushed to the secondary almost instantly — typically within milliseconds, though under load it can take up to a few seconds. This ensures that if a failover occurs, existing sessions continue without being dropped.
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Fortinet exam blueprint
This NSE4 practice question is part of Courseiva's free Fortinet certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the NSE4 exam.