“To reduce the number of log messages generated and improve performance, you can enable a session table entry of dropped traffic. This creates the denied session in the session table and, if the session is denied, all packets for that session are also denied. This ensures that FortiGate does not have to perform a policy lookup for each new packet matching the denied session, which reduces CPU usage and log generation.”
“The CLI command is ses-denied-traffic. You can also set the duration for block sessions. This determines how long a session will be kept in the session table by setting block-session-timer in the CLI. By default, it is set to 30 seconds.”
Technical Deep Dive:
The correct answers are A and B .
When set ses-denied-traffic enable is configured, FortiGate creates a session-table entry for denied traffic . That means once traffic is denied, subsequent packets that belong to the same denied flow do not need a full policy lookup again. FortiGate can drop them immediately based on the existing denied-session entry. That directly confirms B .
Because FortiGate no longer re-evaluates every repeated denied packet in the same way, the device generates fewer logs and uses less CPU for repeated denied traffic. That is exactly why A is also correct.
Why the other two are wrong:
C is incorrect because block-session-timer 30 means 30 seconds , not 30 minutes. The denied session entry is kept in the session table for that duration.
D is incorrect because these settings do not disable session helpers. They only control how denied traffic is tracked in the session table.
In operational terms, this feature is useful when a host repeatedly retries traffic that FortiGate is already denying. Instead of doing a fresh lookup for every retry, FortiGate caches the denied decision temporarily and drops the repeated packets faster.
