How to Enable Logging in FortiGate Firewall Policies for Troubleshooting

 Logging is the one setting that costs nothing while everything works and determines whether you can solve anything when it stops.

The uncomfortable part is that default logging on a FortiGate records almost nothing useful for connectivity troubleshooting. A policy is created, traffic flows, something breaks, and the administrator opens the log expecting answers and finds either nothing at all or only security events unrelated to the problem.

Configuring FortiGate logging properly is a twenty-minute task that pays for itself the first time a user reports that an application cannot connect.

What Gets Logged by Default

Each firewall policy has a setting governing what it records, with two meaningful options.

Log Security Events is the common default. It records only events generated by security profiles — a virus detected, a web category blocked, an intrusion signature matched. Ordinary permitted traffic generates no entry.

Log All Sessions records every session handled by the policy, whether or not anything interesting happened.

For security monitoring, the first is adequate. For troubleshooting connectivity, it is useless — because the question you need answered is almost always "did this traffic reach the firewall at all, and what did the firewall do with it," and that question requires the second setting.

On deny policies, a separate option controls whether violations are logged, and it should be enabled on any deny rule you might need to investigate.

Where the Logs Go

Before enabling extensive logging, know where it is being written. This matters more than it sounds.

• Memory. Available on every model, holds a small amount, and is lost entirely on reboot. Adequate for live troubleshooting, useless for anything historical.
• Local disk. Available only on models that have one. Many small desktop units do not, and some that appear to have storage use flash memory that wears with heavy writing. Check your model before enabling aggressive disk logging.
• FortiAnalyzer. A dedicated appliance or virtual machine for log collection, search, and reporting. The proper answer for any environment with more than one firewall.
• FortiCloud. Fortinet's hosted collection service, with retention depending on subscription level.
• Syslog. Forwarding to any external collector. Flexible, vendor-neutral, and often the most practical option for a small environment that already runs a log server.

The recommendation for a single-firewall site with no analyser: forward to syslog on an inexpensive collector, and use memory logging for live work. Relying on memory alone means every reboot erases the evidence of whatever caused it.

The Setting That Matters Most for Troubleshooting

This one is not obvious and it changes the usefulness of your logs substantially.

By default, FortiGate writes a traffic log entry when a session ends. That entry contains complete information — bytes transferred, duration, and the final outcome.

The problem: a session that is still open has generated no log entry. A user reports a connection hanging right now, you check the log, and there is nothing — because from the firewall's perspective the session has not concluded.

Enabling session-start logging records an entry when the session begins as well:

config firewall policy
    edit <policy-id>
        set logtraffic all
        set logtraffic-start enable
    next
end

This doubles the log volume for affected policies, which is why it is not the default. Enable it selectively on policies you are actively investigating rather than everywhere.

Reading the Forward Traffic Log

The forward traffic log, under Log and Report, is where policy decisions appear. The fields that matter for diagnosis:

• Source and destination address and port. Confirms which conversation you are looking at.
• Policy ID. Which rule handled this session. This single field answers "which policy is matching" definitively.
• Action. Accepted, denied, or closed.
• Service. What the firewall identified the traffic as.
• Sent and received bytes. Zero received on an accepted session means the traffic left and nothing came back — a routing or far-end problem, not a firewall one.
• Duration. Very short sessions often indicate a connection refused rather than blocked.

Build filters rather than scrolling. Filtering by source address, or by destination port, narrows thousands of entries to the relevant handful in seconds.

The interpretation worth learning: an accepted session with bytes sent and zero received is not a firewall problem. The firewall did its job and the destination did not answer. This distinction ends a great many unproductive conversations.

Logging the Implicit Deny

Traffic that matches no policy is dropped by the implicit deny at the bottom of the list, and by default that drop is silent. No log entry, no evidence.

The practical remedy is to create an explicit deny-all policy immediately above the implicit one — any source, any destination, any service, action deny, violation logging enabled.

It behaves identically to the implicit rule and records what it drops. The first time you diagnose a blocked application by reading one line of log output instead of guessing, the configuration pays for itself.

Be aware that on internet-facing interfaces this log fills quickly with scanning traffic. Separate rules for internal and external sources, with logging enabled only on the internal one, keeps the output useful.

The Performance Question

Logging is not free, and the cost varies enormously with configuration.

• Security event logging has minimal impact.
• All-session logging on high-traffic policies generates substantial volume and some processing overhead.
• Session-start logging roughly doubles that volume.
• Disk logging on flash-based models causes wear over time.
• Remote logging consumes bandwidth toward the collector.

The sensible approach is selective: all-session logging on policies covering servers, published services, and anything you routinely investigate; security events only on high-volume general user traffic. Enable session-start temporarily during active troubleshooting and turn it off afterwards.

The Tool That Beats Logs

For a specific session that is failing right now, logs are slower than the diagnostic that shows the firewall's reasoning directly.

The flow debug traces a packet through the firewall's decision process — which policy matched, what routing decision was made, whether translation applied, and precisely where it was dropped.

diagnose debug flow filter addr 10.1.1.50
diagnose debug flow filter port 443
diagnose debug flow show function-name enable
diagnose debug flow trace start 100
diagnose debug enable

Generate the traffic, read the output, then stop cleanly:

diagnose debug disable
diagnose debug reset

Two warnings. This produces a great deal of output, so always set a filter first — running it unfiltered on a busy firewall floods your session and can affect performance. And always disable debugging when finished; leaving it running is a genuine and occasionally serious mistake.

What the flow debug tells you that logs do not: the reason for a drop, stated explicitly. Rather than inferring from an absence of entries, you see a line saying which check failed.

Confirming Which Policy Applies

The policy lookup tool in the graphical interface accepts session parameters — interface, source, destination, protocol, port — and reports which policy would handle that traffic.

Use it before changing anything. A large proportion of policy troubleshooting time is spent modifying a rule that was never involved in the traffic being investigated, and thirty seconds with this tool prevents it.

When You Need the Packets

If logs and flow debug both show the firewall behaving correctly and the problem persists, capture the traffic:

diagnose sniffer packet any 'host 10.1.1.50 and port 443' 4

The trailing number controls verbosity; level 4 includes interface names, which is usually what you want. Output can be saved and converted for analysis in a graphical packet analyser.

This answers the final question: is the traffic actually arriving at the firewall, and is it leaving?

The Other Log Types

Forward traffic is the log you will use most, and it is not the only one. Knowing which log holds which answer saves searching in the wrong place.

• Local traffic. Sessions terminating on the firewall itself rather than passing through it — management access, VPN negotiation, routing protocol exchanges. If someone cannot reach the management interface, this is where to look, not forward traffic.
• System events. Configuration changes, administrator logins, interface state changes, high availability failovers, and reboots. The first place to check when something changed and nobody admits to changing it.
• Security logs, split by feature — antivirus, web filter, intrusion prevention, application control. Each records what its profile detected.
• VPN events. Tunnel establishment and failure, with the negotiation detail that explains why a tunnel will not come up.
• User authentication. Login successes and failures for anything requiring identity.

The system event log deserves particular attention. A surprising share of incidents that present as network faults are traced to a configuration change made hours earlier, and that log records who made it and when. Reviewing it is frequently faster than investigating the symptom.

A Logging Strategy

1. Decide where logs go before enabling anything, and confirm your model supports it.
2. Enable all-session logging on policies covering servers and published services.
3. Leave security-event logging on high-volume user policies.
4. Create an explicit deny-all with violation logging above the implicit deny.
5. Forward to an external collector, so logs survive a reboot or a device replacement.
6. Enable session-start logging temporarily when investigating, and disable it afterwards.
7. Review retention against whatever your organisation requires.
8. Test that logging works before you need it — generate some traffic and confirm entries appear where you expect.

That final step is the one that gets skipped. Discovering during an incident that logs were being written to memory on a device that has just rebooted is a specific and avoidable kind of misery, and it is the main reason FortiGate logging deserves attention on a quiet day rather than a busy one.