FortiGate policy order: why your rule never matches

FortiGate firewalls process security policies in a strict top-to-bottom order. The first matching policy wins, and evaluation stops. If your rule never matches, it is almost always because a higher-priority policy matched first. Understanding policy order is critical for troubleshooting firewall behavior and essential knowledge for NSE certification.

How FortiGate evaluates policies

When a packet arrives at a FortiGate, the firewall compares it against the policy list from top to bottom. The first policy whose conditions match (source interface, destination interface, source address, destination address, service, and schedule) is applied. The packet is then either allowed, denied, logged, or subjected to additional actions like inspection or shaping. No further policies are evaluated.

This means a permissive rule placed above a restrictive rule will always match first. For example, if you have an 'Allow all traffic' policy at the top of your list, no rule below it will ever be evaluated.

Common reasons your rule does not match

• →A broader rule above it matches first - check policies with overlapping source, destination, or service criteria
• →Interface mismatch - the ingress or egress interface does not match your policy condition
• →Address object mismatch - the source or destination IP does not fall within the specified address object or subnet
• →Service mismatch - the traffic uses a port or protocol not included in your service object
• →Schedule restriction - the policy is bound to a schedule that is not currently active
• →Policy is disabled - the policy exists but is explicitly disabled in the GUI or CLI

Viewing and reordering policies

In the FortiGate GUI, navigate to Policy & Objects > Firewall Policy to see the policy list in evaluation order. The policy ID does not determine order; the position in the list does. To change order, select a policy and use the Move Up or Move Down buttons.

In the CLI, list policies with their sequence number:

config firewall policy
  show
end

To move a policy, edit it and set its position. For example, to insert a policy before sequence 5:

config firewall policy
  edit 10
    set name "My New Rule"
    set srcintf "port1"
    set dstintf "port2"
    set srcaddr "Internal"
    set dstaddr "External"
    set service "HTTP" "HTTPS"
    set action accept
  next
end

Debugging with logs and packet capture

Enable logging on the policies you suspect are matching. In the policy details, set Log Allowed Traffic and Log Denied Traffic to All Sessions. Then generate test traffic and examine the logs in Log & Report > Traffic. The log entry will show which policy ID matched.

For deeper inspection, use the FortiGate packet sniffer to capture traffic before policy evaluation. This confirms the packet is arriving with the expected source, destination, and service.

Remember: FortiGate stops at the first match. Always place specific rules before general ones. A common best practice is to order policies by specificity: most specific conditions first, then progressively broader rules, with a final implicit deny at the bottom.