FortinetConfig1,087 downloads

Fortinet FortiGate Firewall Policies

FortiGate security policy configuration with address objects, service objects, UTM profiles, and IPv4 firewall policies.

↓ example.txt

What is it?

FortiGate firewall policies are stateful rules that control which traffic is allowed between interfaces. Unlike Palo Alto's zone-based model, FortiGate policies match on source interface and destination interface — not zones. Each policy can optionally apply UTM profiles: Antivirus, IPS sensor, Web Filter, and Application Control. The 'nat enable' flag inside a policy enables source NAT using the outgoing interface IP — a quick way to enable internet access without separate NAT objects. Policies are evaluated top-down; the first match wins.

When to use

·Allowing or blocking traffic between any two network segments (LAN to WAN, DMZ to LAN, etc.)
·Applying security scanning (AV, IPS, web filtering) to traffic flows
·Enabling NAT for internet-bound traffic directly within the policy

When NOT to use

·For complex DNAT/VIP scenarios — use FortiGate VIP objects with separate policies instead of inline NAT
·If you need application visibility without blocking — enable application logging first and build policies from actual traffic data

How it compares

vs Palo Alto Security PolicyPalo Alto uses zones (not interfaces) and App-ID for application identification. FortiGate uses srcintf/dstintf and has its own App Control engine. Palo Alto is deny-by-default; FortiGate also defaults to implicit deny at the bottom.

vs Cisco ASA ACLASA uses ACLs applied to interfaces with 'access-group'. FortiGate uses unified policies with built-in UTM. ASA has no built-in AV/IPS — requires separate FirePOWER module.

Prerequisites

→Source and destination interfaces must be configured before referencing in policies
→Address objects should be created before policies reference them (or use 'all' for testing)
→UTM profiles (AV, IPS, web filter) must be created before applying to policies
→Policies are evaluated in order — place more specific rules above broader rules

Config Generator

Hostname *

Address Objects

Address Groups

Firewall Policies

Verification commands

get firewall policy

List all firewall policies with IDs, names, and actions

ExpectedShows all policies in order. Verify the expected policy exists and has correct srcintf/dstintf.

diagnose firewall iprope lookup <src-ip> <dst-ip> <sport> <dport> <proto> <src-if>

Test which policy matches specific traffic

ExpectedReturns the policy ID and action (accept/deny) that would apply to this traffic

Debug commands

diagnose debug flow filter addr <src-ip>

Enable packet flow debug for a specific source IP

WarningUse in maintenance window — generates verbose output. Disable after: 'diagnose debug flow filter clear'

Common mistakes & fixes

SymptomTraffic blocked even though a policy exists

CauseA deny policy above the allow policy is matching first, or wrong srcintf/dstintf

FixUse 'diagnose firewall iprope lookup' to identify which policy actually matches. Move the allow policy above the deny, or fix srcintf/dstintf.

SymptomUTM blocking legitimate traffic

CauseIPS sensor or AV profile with aggressive settings triggering false positives

FixCheck UTM logs: 'Log & Report > Security Events'. Identify the specific signature/category and create an exemption in the profile.

SymptomPolicy with 'nat enable' not NATting traffic

CauseCentral NAT mode is enabled — in central NAT mode, policy-based NAT is ignored

FixCheck: 'config system settings > get > central-nat'. If enabled, NAT must be configured in 'config firewall central-snat-map' instead.

Further learning

Recommended books to go deeper on this topic.

Palo Alto Networks Firewall Deployment and Administration

Tom Piens · Packt · Security policies, App-ID, User-ID, service objects — the PAN-OS bible

Kindle ↗Hardcover ↗Paperback ↗

Network Security Architectures

Sean Convery · Cisco Press · Firewall design patterns and policy best practices — vendor-agnostic

Hardcover ↗