Why FortiGate Doesn't Automatically Clear Sessions When a Policy Is Deleted
An admin runs 'diagnose sys session filter dport 443' and sees output showing sessions with 'proto=6' and 'expire=3599'. The admin notices that these sessions are not being cleaned up after the firewall policy that allowed them is deleted. What is the reason?
Quick Answer
The answer is that FortiGate does not automatically clear existing sessions when a policy is deleted; sessions must be cleared manually. This occurs because FortiGate’s session table operates independently from the policy table—once a session is established and its state is tracked, the firewall continues to forward packets for that session until it expires naturally or is explicitly terminated, even if the original policy is removed. On the Fortinet NSE 4 Network Security Professional exam, this concept tests your understanding of stateful inspection and session lifecycles, often appearing as a trap where candidates assume policy changes instantly affect active flows. A common memory tip is to think of sessions as “frozen in time”—they don’t check policies again until they expire. Remember the mnemonic: “Delete the rule, not the session; clear the table for a clean impression.”
⚠ Common exam trap
Candidates often assume FortiGate automatically removes sessions when a policy is deleted, similar to how some other firewalls handle stateful inspection, but FortiGate requires manual intervention or timeout expiration to clear sessions.
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
✓
FortiGate does not delete existing sessions when a policy is removed; sessions must be cleared manually
When a firewall policy is deleted on a FortiGate, the existing sessions that were created by that policy are not automatically removed. The FortiGate continues to process those sessions until they expire naturally based on their timeout values. In this case, the sessions with 'proto=6' (TCP) and 'expire=3599' seconds remaining will persist until the timer counts down, even though the originating policy no longer exists. The admin must manually clear them using 'diagnose sys session clear' or wait for the timeout to expire.
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 sessions are using UDP protocol, which has a longer timeout
Why it's wrong here
The output shows proto=6, which is TCP, so the UDP timeout explanation contradicts the displayed protocol; session expiry is governed by TCP state timers, not UDP. It is tempting because UDP sessions do have differing timeout behaviour, which would be relevant had the output shown proto=17.
- ✗
The sessions are protected by a different policy that still exists
Why it's wrong here
Deleting a policy removes its sessions; a surviving policy would appear as a separate session entry with its own policy ID, not as sessions lingering from the deleted one. It is tempting because overlapping policies genuinely can keep traffic alive, which is the correct diagnosis when session output references a policy still present.
- ✗
The sessions are in a different VDOM
Why it's wrong here
Session cleanup after policy deletion is not scoped by VDOM membership; sessions in any VDOM tied to the deleted policy are removed. It is tempting because VDOMs do isolate policies and sessions, so cross-VDOM visibility issues are a genuine cause when sessions appear missing from the expected VDOM.
- ✓
FortiGate does not delete existing sessions when a policy is removed; sessions must be cleared manually
Why this is correct
FortiGate evaluates policies only for new sessions; deleting a policy does not tear down sessions already established under it. Those entries persist until expiry or manual clearing via diagnose sys session clear, satisfying the stated scenario.
Go deeper
Related to this question
About these practice questions
This NSE4 question is part of Courseiva's 773-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way 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. A FortiGate admin runs 'diagnose sys session filter src 10.0.0.10' and gets no output. What does this indicate?
medium- A.The session table is full
- ✓ B.The source IP 10.0.0.10 is not currently active in any session table
- C.The firewall policy is blocking traffic from 10.0.0.10
- D.The diagnose command syntax is incorrect
Why B: The 'diagnose sys session filter' command in FortiGate is used to filter and display active session entries in the session table. When the command 'diagnose sys session filter src 10.0.0.10' returns no output, it means that no session in the session table matches the source IP address 10.0.0.10, indicating that this IP is not currently involved in any active session. This does not imply the session table is full, a policy block, or a syntax error.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.