FortiGate Firewall Policy Management Guide

FortiGate firewall policies are rules that decide how traffic is handled based on source, destination, user, service, and schedule criteria. Policies are evaluated top to bottom; the first matching rule applies, and if none match an implicit deny takes effect.

What Is a Firewall Policy and How Does It Work?

A firewall policy is a rule that permits or blocks traffic from a given source to a given destination. FortiGate matches each new session top-down against the policy list and applies the action of the first matching rule.

In FortiOS a policy is evaluated against a session's first packet. Once a match is found, the session is pinned to that rule and subsequent packets follow it. That is why ordering directly determines the security outcome.

Policies can be defined per interface pair (e.g., LAN to WAN) or via the flat policy table preferred in FortiOS 7.x. The logic is identical in both: specific rules on top, general rules below.

Base setup must be complete before you create policies; see our FortiGate installation and initial configuration guide.

The Components of a Policy

Policy components consist of incoming/outgoing interface, source and destination address, service, schedule, action (accept/deny), NAT, and the security profiles to apply.

Each component narrows the match criteria or defines behavior. If the action is accept, NAT, logging, and security profiles can engage; if deny, the traffic is dropped.

To attach security profiles to a policy, see our UTM security profiles guide; for remote-access policies, read our VPN configuration article.

Managing Address and Service Objects

Object management means defining IP/subnet, FQDN, and geographic addresses and custom services as reusable objects; groups then simplify them.

Under Policy & Objects > Addresses, create subnet, IP-range, FQDN, or geo-based address objects. Collecting repeated destinations under an address group lets you manage with one rule instead of dozens.

Define Service objects for custom applications and build service groups. Well-named objects greatly improve policy readability during audits and troubleshooting.

• Create subnet/IP-range/FQDN/geo address objects.
• Collect repeated addresses into groups.
• Define custom service objects for non-standard ports.
• Name objects with a consistent naming scheme.
• Clean up unused objects regularly.

Ordering, Matching, and Implicit Deny

Ordering is at the heart of FortiGate security: rules are scanned top-down, the first match applies, and if nothing matches the invisible implicit deny blocks the traffic.

Place more specific rules (narrow address/service) at the top of the list and more general rules below. Incorrect ordering can cause strict rules beneath a broad allow rule to never run.

Use the policy lookup tool and the session table to see which rule a session lands on. Enabling logging for the implicit deny rule makes blocked traffic visible and eases debugging.

To manage the performance impact of many rules, see our performance optimization and best-practices guide.

Best Practices in Policy Management

Best practices include least privilege, meaningful naming, regular rule audits, cleaning up unused rules, and documenting changes.

Limit each rule to only the required source, destination, and service; avoid any-any-allow rules. Add comments to rules and apply a change-logging discipline.

Periodically review unused or conflicting rules; FortiOS policy usage counters reveal which rules never match. This cleanup improves both security and performance.

For central visibility and change auditing, read our logging and monitoring with FortiAnalyzer article, and for overall architecture our what is FortiGate guide.

Frequently Asked Questions

In what order are FortiGate policies evaluated?

Policies are evaluated top to bottom. A session is subject to the action of the first rule it matches; later rules are not checked for that session.

What is implicit deny?

It is the invisible default rule at the end of the policy list that blocks all traffic matching no rule. Enabling logging for it makes blocked traffic visible.

What is the benefit of an address group?

It collects repeated destinations under a single group, allowing management with one rule instead of dozens; changes made in one place reduce the risk of error.

Do I configure NAT inside the policy?

Yes, in most scenarios source NAT is enabled on the policy via the NAT option. For more complex cases, IP pools or central NAT can be used.

How do I see which rules are unused?

FortiOS policy usage counters (hit count) and last-used data surface rules that never match. These can be reviewed and safely removed.

How do I make policy changes safely?

Take a configuration backup first, comment your rules, verify impact with policy lookup, and apply changes in a maintenance window where possible.

Conclusion

FortiGate policy management produces a rule set that is both secure and manageable through correct ordering, a clean object structure, and least privilege. Regular auditing and logging keep policies from degrading over time.

For a policy-hygiene audit and reconfiguration, contact the Sora Yazılım security team.