A FortiGate administrator notices that traffic from a specific subnet is being dropped unexpectedly. The security policy allows the traffic, and there are no firewall policies blocking it. What is the most efficient first step to identify the cause of the drops?
Trap 1: Run 'diagnose debug flow' with the source IP and look for 'no…
Debug flow traces a packet's path and shows the exact drop reason, including policy lookup failures, so it directly identifies the cause. It is tempting because it is FortiOS's standard packet-tracing tool, and it would be the right first step when the drop point is unknown rather than already narrowed to this subnet.
Trap 2: Enable 'deny-log' on all policies and check logs for the subnet.
Deny-log records dropped packets but does not reveal why the FortiGate dropped them, and enabling it on all policies is broad. It would be correct when the requirement is ongoing audit logging of denied traffic, not rapid diagnosis of a specific subnet's unexpected drops.
Trap 3: Enable global traffic logging and review logs after some traffic…
Global traffic logging captures large volumes of session data without pinpointing the drop reason, and it requires traffic to pass before review. It suits compliance or forensic retention of traffic records, not the immediate diagnosis of why a specific subnet's packets are being dropped.
- A
Use the 'diag sniffer packet any "host 10.0.1.0/24" 4' command to capture packets and analyze where they are dropped.
The sniffer captures packets at the interface level with verbose output, revealing whether traffic arrives and where it is discarded. Because policy already permits the subnet, the drop must originate elsewhere, such as routing, UTM inspection or a local-in policy, which the capture exposes.
- B
Run 'diagnose debug flow' with the source IP and look for 'no matching policy' or 'dropped' messages.
Why it fails: Debug flow traces a packet's path and shows the exact drop reason, including policy lookup failures, so it directly identifies the cause. It is tempting because it is FortiOS's standard packet-tracing tool, and it would be the right first step when the drop point is unknown rather than already narrowed to this subnet.
- C
Enable 'deny-log' on all policies and check logs for the subnet.
Why it fails: Deny-log records dropped packets but does not reveal why the FortiGate dropped them, and enabling it on all policies is broad. It would be correct when the requirement is ongoing audit logging of denied traffic, not rapid diagnosis of a specific subnet's unexpected drops.
- D
Enable global traffic logging and review logs after some traffic passes.
Why it fails: Global traffic logging captures large volumes of session data without pinpointing the drop reason, and it requires traffic to pass before review. It suits compliance or forensic retention of traffic records, not the immediate diagnosis of why a specific subnet's packets are being dropped.