Should I log all sessions on every policy?

Log all sessions where you need a record of who connected where, such as Internet access and access to servers. Very busy internal policies can log security events only, to save log space; the choice depends on your audit needs and log storage.

Why does my LAN-to-DMZ policy have NAT off?

Both networks are yours and routed directly by the FortiGate, so translation isn't needed, and the server's logs then show the real client address. NAT is mainly for leaving towards the Internet.

Configuring FortiGate Firewall Policies in the GUI and CLI | FortiGate Course

A real-life situation

FGT1 is online, but PC1 still can't browse: the implicit deny drops everything. Staff need web access to the Internet, and the LAN must reach the DMZ web server for testing, but only on HTTP and HTTPS. This lesson builds those two policies and a logged catch-all deny.

The policy form, field by field

In the GUI: Policy & Objects › Firewall Policy › Create New.

Name: required by default and unique. Name the purpose: LAN-to-Internet.
Incoming / Outgoing Interface: port2 → port1.
Source / Destination: LAN-subnet → all.
Schedule: always. Service: HTTP, HTTPS, DNS.
Action: ACCEPT.
NAT: on, using the outgoing interface address (203.0.113.2).
Security profiles: none yet (module 6).
Log Allowed Traffic: All Sessions.
Comments: why the policy exists and who asked for it.

The same in the CLI

config firewall policy
    edit 1
        set name "LAN-to-Internet"
        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
        set logtraffic all
        set comments "Staff web access"
    next
    edit 2
        set name "LAN-to-DMZ-Web"
        set srcintf "port2"
        set dstintf "port3"
        set srcaddr "LAN-subnet"
        set dstaddr "WEB1"
        set action accept
        set schedule "always"
        set service "HTTP" "HTTPS"
        set logtraffic all
    next
    edit 99
        set name "Deny-All-Log"
        set srcintf "any"
        set dstintf "any"
        set srcaddr "all"
        set dstaddr "all"
        set action deny
        set schedule "always"
        set service "ALL"
        set logtraffic all
    next
end

Policy 2 has NAT off: the DMZ server sees PC1's real address. Policy 99 is an explicit deny with logging at the bottom, so dropped traffic appears in the logs (it does what the implicit deny does, but visibly). New policies are added at the bottom, so keep 99 last.

Ordering, disabling and cloning

config firewall policy
    move 3 before 1
    edit 3
        set status disable
    next
end

move changes the sequence (in the GUI, drag the policy). Disabling keeps a policy in place for later while it matches nothing. In the GUI, right-click › Clone copies a policy to edit.

Two GUI views help: Interface Pair View groups policies by their interfaces, and By Sequence shows the real order. When a policy uses any as an interface, only the sequence view shows where it really sits.

Keeping the rule base clean

Example output · based on Fortinet documentation; exact format varies by model and FortiOS version

FGT1 # diagnose firewall iprope show 100004 1
idx=1 pkts/bytes=15873/12704118 asic_pkts/asic_bytes=0/0 nturbo_pkts/nturbo_bytes=0/0 flag=0x0 hit count:412 (...)
 first:2026-10-11 09:02:17 last:2026-10-11 16:41:03
 established session count:23

Hit count, first and last use for policy 1 (100004 is the table of forward policies). The GUI shows the same in the Hit Count, First Used and Last Used columns. Example output, trimmed.

Review policies with zero hits after a few months: they may be unused, or shadowed by a broader policy above them.
Prefer specific objects and services to all and ALL.
Group related policies into sections (sequence grouping) in the GUI, and comment every policy.

Why it works this way

The firewall can only enforce what the rule base says, so a readable rule base is a security control in itself. Names, comments, narrow objects and logging make it possible to answer, months later, why a policy exists and what it is doing.

Common mistakes

Leaving NAT off on the Internet policy: outbound packets leave with private source addresses and replies never return.
Adding a new policy and forgetting that it went to the bottom, below a catch-all deny.
Using any interfaces casually: it removes the interface pair view and widens the policy.
Turning logging off to save space on the policies you will later need to investigate.

Key takeaways

✅ Key takeaways

A policy: name, interfaces, source, destination, schedule, service, action, NAT, profiles, logging.
NAT on for the Internet; usually off between your own networks.
New policies are added at the bottom; use move (or drag) to place them.
Hit counts and last-used times show unused or shadowed policies.

Check yourself

Predict · scenario 1

PC1 matches LAN-to-Internet (accept) but web pages never load. The traffic log shows the session with a source of 10.0.1.10 leaving port1. What is missing?

Predict · scenario 2

You create a new accept policy, but it never matches. A logged deny-all policy is in the list. Why?

Predict · scenario 3

A policy has a hit count of 0 after six months. What are two likely explanations?

Configuring firewall policies

What you will learn