Create and Correctly Order Firewall Policies on a FortiGate

FortiGate evaluates IPv4 policies top to bottom, first match wins. A correct rule in the wrong position does nothing, or worse, a broad "allow" above a specific "deny" quietly opens traffic you meant to block. This guide covers creating a standard IPv4 policy and placing it in the right spot, on FortiOS 7.4 (the same steps apply across 7.2–7.6, but menu labels and CLI keywords can shift between minor versions, so confirm against your build).

Before you run this

What this does: creates one or more IPv4 firewall policies (source/destination interface, address objects, service, action, NAT, logging) and moves them into the correct evaluation order. Firewall policy changes take effect immediately — there is no staged commit on FortiOS.

Privileges: you need an administrator account with write access to firewall policy. A read-only or profile-restricted admin cannot save these changes.

This changes live traffic. A policy that is too broad, or ordered above a deny, passes traffic the moment you save it. A wrong srcintf/dstintf pair or a NAT mistake can also cut production flows or lock you out of management.

Before you touch anything:

Keep an out-of-band path open — a console cable, or an SSH/HTTPS session from a management network you are certain your change won't affect. If you manage the FortiGate over the same interface pair you're editing, one bad rule can drop your own session.
Back up the running config first (below). Restoring that file is your rollback.
Do it in a maintenance window. Test the logic on a lab FortiGate or a VM (FortiGate-VM images are available) before running it against production, and start with a single narrow test policy rather than rewriting the whole rule base at once.

FortiOS has no timed auto-rollback for policy edits, so your undo is: delete the policy you added, or restore the config backup you took.

Back up before you change anything

GUI: top-right, click the admin name → Configuration → Backup. Choose Local PC, and save the .conf file.

CLI: the standard command is execute backup config, followed by the destination (for example tftp, usb, or flash) and its parameters. Run execute backup config ? to see the exact arguments your firmware expects rather than guessing them.

If your unit has configuration revision saving enabled (System → Settings, revision options), you'll also have on-flash revisions you can revert to — but treat the .conf file as your primary safety net.

Assumptions

FortiOS 7.4, IPv4 policies (the classic Firewall Policy, not the newer consolidated/policy-based-NGFW modes).
port2 is your internal/LAN interface, port1 faces the internet. Substitute your own interface names — check Network → Interfaces.
The example: allow the LAN subnet outbound web and DNS, with source NAT.

Create the address object first

Policies reference objects, not raw subnets, so define the source first.

config firewall address
    edit "LAN_Subnet"
        set subnet 192.168.10.0 255.255.255.0    # replace with your subnet
    next
end

all is the built-in "any address" object; you don't create it.

Create the policy

GUI

Policy & Objects → Firewall Policy.
Click Create New.
Fill in:
- Name: LAN-to-WAN-Web (name it something you'll recognise in logs)
- Incoming Interface: port2
- Outgoing Interface: port1
- Source: LAN_Subnet
- Destination: all
- Schedule: always
- Service: HTTP, HTTPS, DNS
- Action: ACCEPT
Under Firewall / Network Options, enable NAT, and leave Use Outgoing Interface Address selected (this is standard source NAT to the WAN IP). To NAT to a pool instead, select an IP pool object you've already created.
Set Log Allowed Traffic to All Sessions while you're validating, then reduce to Security Events later if you prefer less log volume.
OK.

CLI

config firewall policy
    edit 0                                  # 0 = auto-assign the next free policy ID
        set name "LAN-to-WAN-Web"
        set srcintf "port2"
        set dstintf "port1"
        set srcaddr "LAN_Subnet"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "HTTP" "HTTPS" "DNS"
        set nat enable                       # source NAT to the outgoing interface IP
        set logtraffic all
    next
end

To attach security profiles (antivirus, web filter, IPS), you also set set utm-status enable and the individual profile fields — the exact keywords (e.g. set av-profile, set ssl-ssh-profile) depend on which profiles you use. Confirm the profile field names in the FortiOS CLI Reference for your version before adding them; don't guess profile names.

Understand and fix the order

The policy ID is not the order. FortiOS assigns IDs in creation order, but you can move policies anywhere, and evaluation follows the sequence, not the number. Two things matter:

More specific policies go above more general ones.
A deny must sit above any broader allow it's meant to override.
Anything not matched hits the implicit deny at the bottom (policy ID 0), which drops the traffic.

View the real order

GUI: in Firewall Policy, switch the view (top of the list) to By Sequence. This shows policies in evaluation order regardless of ID.

CLI: show firewall policy lists them in evaluation order.

Move a policy

GUI (By Sequence view): drag the policy row to its new position, or right-click → Move → Up/Down/Before/After.

CLI: use the move command inside the policy table. To place policy 12 immediately before policy 5:

config firewall policy
    move 12 before 5
end

move <id> after <id> also works. This changes only the sequence, not the ID or any settings.

Worked example of the ordering trap: suppose you have a broad allow (LAN → WAN, all services) as ID 5, and you now add a deny for a blocked-hosts group as ID 12. Created last, ID 12 sits below ID 5 and never triggers. move 12 before 5 puts the deny first, so blocked hosts are dropped before the general allow can match them.

Verify

Confirm the policy exists and its order:

show firewall policy 12          # inspect one policy by ID
show firewall policy             # full list, in evaluation order

Confirm it's actually matching traffic: in the GUI Firewall Policy list, the Bytes / Sessions counters increment on a matched policy. If a policy stays at zero while you know matching traffic is flowing, something above it is matching first — recheck the order.

Use the Policy Lookup tool: in Policy & Objects → Firewall Policy, the Policy Lookup button lets you enter a source interface, source/destination IP, protocol and port, and FortiOS tells you which policy would match. This is the safest way to confirm order without generating real traffic. (If you don't see the button, confirm it's available in your firmware from the FortiGate Administration Guide.)

Test real traffic from a host in the source subnet — browse to an external site, resolve DNS — and watch Log & Report → Forward Traffic for the hits, tagged with your policy name.

Undo

Remove a single policy you just added (CLI):

config firewall policy
    delete 12                    # use the actual ID from 'show firewall policy'
end

GUI: right-click the policy → Delete.

Revert an ordering change: move it back with the move command (or drag it back in By Sequence view).

Full rollback: restore the .conf you saved. GUI: admin name → Configuration → Restore → Local PC. Restoring a full config replaces the entire running configuration and typically reboots the unit — do it from a connection that survives a reboot, ideally the console. Confirm the restore command and its behaviour in the FortiOS admin guide before you rely on it in production.