NSE4 Lab: Troubleshooting Policy Logs for Blocked Traffic

When users report connectivity issues on a FortiGate-protected network, the first place to look is the policy log. The NSE4 lab on troubleshooting policy logs for blocked traffic teaches you to read these logs accurately, identify the root cause of denials, and validate fixes. This skill is critical for any network engineer managing Fortinet infrastructure in production.

Understanding FortiGate Policy Logs

FortiGate logs every packet decision at the policy level. When traffic is blocked, the firewall records the source and destination IP addresses, ports, protocol, the policy that matched (or didn't match), and the action taken. Unlike raw packet captures, policy logs are human-readable and directly tied to your firewall rules.

The key fields in a policy log entry are: source IP, destination IP, source port, destination port, protocol, policy ID, policy name, and action (accept or deny). A blocked traffic entry shows action=deny and points you to either a missing rule or an explicit deny rule that caught the traffic.

Common Causes of Blocked Traffic

• →No matching policy rule exists for the traffic flow
• →An explicit deny rule is positioned before the allow rule
• →Source or destination address objects are misconfigured
• →Port or service definitions do not match the actual traffic
• →Implicit deny-all rule at the end of the policy list
• →Traffic is blocked by an IPS or application control signature
• →Source or destination is in a blacklist or security profile

Reading and Filtering Policy Logs

In the FortiGate GUI, navigate to Log & Report > Forward Traffic to view policy logs in real time. You can filter by source IP, destination IP, action, or policy ID to isolate the blocked traffic you are investigating.

# Example: View policy logs via CLI
diagnose test application firewall read-log
diagnose debug flow trace start 100
diagnose debug flow show console

# Example: Filter logs by destination IP
get log forward filter destination 192.168.1.50

Once you identify a blocked entry, note the policy ID. Then check the actual policy rule to confirm whether it should allow or deny that traffic. If the rule should allow it, verify that the address objects, service objects, and interface settings match the real traffic.

Lab Workflow: Diagnosis and Validation

A typical NSE4 lab scenario presents a user complaint: 'I cannot reach the web server.' You log into the FortiGate, enable policy logging if needed, and ask the user to attempt the connection again. The policy log immediately shows you whether the traffic arrived at the firewall and which rule (or lack of rule) caused the block.

From there, you create or modify a policy rule to allow the traffic, verify the rule order, and confirm that the source and destination objects are correct. Finally, you test the connection end-to-end and check the log again to see action=accept for the same traffic flow.

This cycle of log reading, rule review, rule modification, and re-testing is the foundation of firewall troubleshooting. Mastering it on NSE4 labs prepares you for real-world scenarios where a single misconfigured port or service definition can block critical business traffic.

Pro Tips

• →Always enable policy logging on rules you are troubleshooting; it has minimal performance impact
• →Use named address and service objects; they make logs and policies far easier to read and audit
• →Check policy order first; FortiGate processes rules top-to-bottom and stops at the first match
• →If you see deny entries but no matching explicit deny rule, the implicit deny-all at the end caught it
• →Cross-reference port numbers in logs with your service definitions; a mismatch is a common root cause