FortiGate NSE4 Lab: Implicit Deny and Why Your Permit Rule Isn't Working

FortiGate firewalls operate on a fundamental principle: if no explicit permit rule matches traffic, the traffic is denied. This implicit deny stance is a security best practice, but it trips up many NSE4 candidates and network engineers when their carefully crafted permit rules mysteriously fail to allow legitimate traffic. Understanding rule evaluation order, policy direction, and the interaction between explicit rules and implicit deny is essential for both lab success and production troubleshooting.

How Implicit Deny Works on FortiGate

Every FortiGate security policy operates within a default-deny framework. When a packet arrives at the firewall, FortiGate evaluates it against the security policy table from top to bottom. The first rule that matches the source interface, destination interface, source address, destination address, service (port and protocol), and schedule determines the action: accept, deny, or other. If no rule matches, the packet is implicitly denied and logged (if logging is enabled).

This means a permit rule that looks correct on paper may fail for several reasons: the rule sits below a conflicting deny rule, the rule is disabled, the addresses or services do not match the actual traffic, the interfaces are reversed, or the rule is associated with the wrong policy direction (inbound versus outbound on the interface pair).

Common Reasons Your Permit Rule Fails

• →Rule order: A deny rule above your permit rule will match first and block traffic before your permit rule is evaluated.
• →Interface mismatch: Rules are directional. A rule from port1 to port2 does not apply to traffic from port2 to port1.
• →Address or service mismatch: The source or destination address object, or the service definition, does not match the actual traffic.
• →Rule disabled: The rule exists but is toggled off in the policy table.
• →Implicit deny logging: Traffic is denied silently if logging is not enabled; enable 'Log Allowed Traffic' and 'Log Denied Traffic' to verify.
• →Policy direction confusion: Ingress and egress policies are separate; ensure your rule is in the correct direction.
• →NAT interaction: Source or destination NAT may alter the packet before the security policy is evaluated, causing the rule to miss.

Troubleshooting Workflow

Start by enabling detailed logging on the suspected rule. In the FortiGate CLI or GUI, set 'Log Allowed Traffic' and 'Log Denied Traffic' to on. Then generate test traffic from the source to the destination and check the FortiGate logs (Logs & Reports > Traffic Logs or CLI: diagnose debug flow trace start). Look for whether the traffic is hitting your rule or being dropped before it reaches the rule.

# Enable detailed logging for a specific policy
config firewall policy
  edit 1
    set logtraffic all
  next
end

# View traffic logs in real-time
diagnose debug flow trace start
# (generate test traffic)
diagnose debug flow trace stop

Verify that the source and destination addresses in the rule match the actual source and destination IPs of the traffic. Check that the service definition includes the correct port and protocol. If the traffic is being denied before reaching your rule, a rule higher in the policy table is matching it first; reorder your rules so that more specific deny rules sit below more specific permit rules, or combine related rules into a single policy with multiple service objects.

Best Practices for NSE4 Labs and Production

• →Order rules from most specific to least specific: Specific rules should appear before general rules to avoid premature matching.
• →Use explicit deny rules sparingly: Rely on implicit deny for traffic that does not match any permit rule.
• →Test rule order: Use the CLI 'diagnose firewall policy list' command to view the compiled policy table and verify rule precedence.
• →Log all traffic during troubleshooting: Enable logging on suspect rules to confirm traffic is reaching the rule.
• →Document rule intent: Add comments to rules explaining why they exist; this aids troubleshooting and peer review.
• →Understand port numbers: Know which services use which ports; refer to a port reference guide when defining services.