Decoding Every Field in a FortiGate Traffic Log: The Complete Reference

By Manny Fernandez

September 11, 2026

Decoding Every Field in a FortiGate Traffic Log: The Complete Reference

Executive Summary

Objective: Give you a field by field reference for FortiOS Traffic logs, built around a real captured log rather than a sanitized textbook example, so you can read any FortiGate log line and know exactly what every token means.

Target audience: Network and security engineers who work with FortiGate firewalls day to day and need to interpret raw logs during troubleshooting, threat hunting, or compliance review, whether the logs are viewed on the FortiGate GUI, pulled from FortiAnalyzer, or shipped to a third party SIEM.

A FortiGate log line looks intimidating the first time you see it in raw form. It is a long string of key=value pairs with no obvious grouping. Once you know the categories those fields fall into, the same line reads almost like a sentence. This guide breaks the fields into those categories, then walks through a real log, field by field, to prove it out.

The Log We Are Decoding

Here is the raw log this guide is built around:

logver=0706063652 idseq=236394707511410688 itime=2026-09-08 18:19:53 reporting_ip=10.250.59.214 devid=FG6H1ETB20902601 vd=root date=2026-09-08 time=18:19:52 eventtime=1788905987031836316 tz=-0400 logid=0000000007 type=traffic subtype=forward level=warning srcip=10.1.105.32 srcport=51120 srcintf=FDZ-OFF srcintfrole=lan srcssid=FDZ-OFF apsn=PU431F5E19000557 ap=FORTIAP-02 channel=149 radioband=802.11ac (5G) signal=-48 snr=41 dstip=192.184.68.254 dstport=443 dstintf=unknown-0 dstintfrole=undefined srccountry=Reserved dstcountry=United States proto=6 action=deny policyid=0 policytype=policy service=HTTPS trandisp=noop appcat=unscanned duration=0 sentbyte=0 rcvdbyte=0 sentpkt=0 rcvdpkt=0 msg=no session matched dtime=2026-09-08 18:19:52 devname=LAB-601E

In one sentence: a wireless client on a FortiAP managed SSID tried to reach an HTTPS destination, the FortiGate found no matching session in its state table for the packet, and denied it, even though the wireless link itself was strong and clean. That last part matters, and we will come back to it after covering every field category.

This particular log also happens to have travelled through a log collector before you saw it. Notice the four fields sitting in front of the fields the FortiGate itself writes (logver, idseq, itime, reporting_ip). Those are added by whatever received the log, typically FortiAnalyzer or a syslog relay, not by the FortiGate. We will flag which fields belong to which layer as we go.

How FortiOS Organizes Its Logs

Every FortiOS log entry carries a type and a subtype. Type is the broad log file the entry belongs to (traffic, event, UTM, and so on). Subtype narrows it down within that type. For Traffic logs specifically, FortiOS has used four subtypes since early FortiOS 5.x, and still does in current 7.6.x builds:

Subtype	What generates it
`forward`	Traffic passing through the FortiGate between two interfaces, matched against a firewall policy. This is the subtype you will see the most, and the one in our captured log.
`local`	Traffic that originates from or terminates on the FortiGate itself, such as GUI/SSH admin access, DNS or NTP lookups the FortiGate makes, RADIUS/LDAP queries, or routing protocol hellos.
`multicast`	Traffic matched against a multicast policy, typically PIM or IGMP driven forwarding where the destination is a multicast group address.
`sniffer`	Traffic observed by a one-arm sniffer interface. Sniffer mode only watches traffic, it never forwards it, so these logs have no real destination interface or NAT fields.

Newer FortiOS 7.6 builds added two more Traffic subtypes worth knowing about even though they are outside the scope of this guide: ztna for Zero Trust Network Access proxy sessions, and http-transaction for per-transaction HTTP/HTTPS logging when that feature is enabled on a policy.

Universal Header Fields

These fields show up on every FortiOS log entry regardless of type, plus the collector fields that get prepended when a log passes through FortiAnalyzer or a syslog relay before you view it.

Field	Meaning
`logver`	The log schema/format version the rest of the message was written against. Added by the collector, not the FortiGate itself. Parsers use it to know which field layout to expect.
`idseq`	A globally unique sequence identifier assigned by the log collector, used for deduplication and correlation, especially useful in HA pairs or when several FortiGates feed one FortiAnalyzer.
`itime`	Insertion time: the local time the collector (typically FortiAnalyzer) received and stored the log. This can lag slightly behind the FortiGate’s own date/time fields.
`reporting_ip`	The IP address of the device that actually sent this log to the collector. Usually matches the FortiGate’s management IP, but can differ if the log passed through a relay.
`devid`	Serial number of the FortiGate that generated the log.
`devname`	Hostname configured on the FortiGate.
`vd`	The VDOM the log was generated in. If VDOMs are not in use, this is always root.
`date` / `time`	The date and time the FortiGate itself recorded the event, in its configured local time zone.
`eventtime`	Epoch timestamp (nanosecond resolution on current builds) marking when the event actually occurred on the FortiGate. It can differ very slightly from date/time because of the gap between the event firing and the log being written.
`tz`	The FortiGate’s configured time zone offset from UTC.
`logid`	A 10 digit identifier that classifies exactly what kind of message this is. The first two digits identify the log type, the next two the subtype or event category, and the last six the specific message ID.
`type`	The top level log category (traffic, event, utm, and so on).
`subtype`	The subcategory within that type, covered above for Traffic logs.
`level`	Severity of the entry: emergency, alert, critical, error, warning, notification, or information.
`dtime`	A FortiAnalyzer calculated timestamp derived from the device’s own date and time fields, normalized to UTC for cross-device correlation.

Core Traffic Fields: The Five-Tuple, Policy Match, and Session Accounting

This is the heart of every Traffic log entry: who talked to whom, over what, which policy allowed or denied it, and how much data moved.

Field	Meaning
`srcip` / `srcport`	Source IP address and port of the session’s originator.
`dstip` / `dstport`	Destination IP address and port.
`srcintf` / `dstintf`	The interface the traffic entered and exited on. For SSID based wireless interfaces, this shows the SSID name (as in our captured log). If the FortiGate never resolved a real egress interface, this shows a placeholder like `unknown-0`.
`srcintfrole` / `dstintfrole`	The role assigned to those interfaces under Network > Interfaces (lan, wan, dmz, or undefined).
`srccountry` / `dstcountry`	Geolocation of the source and destination IP, resolved against FortiGuard’s IP geolocation database. Private, RFC 1918, and other non-routable ranges show as Reserved.
`proto`	The IANA protocol number. The common ones you will see constantly: TCP is 6, UDP is 17, ICMP is 1.
`sessionid`	The FortiGate’s internal session table ID for this flow.
`policyid`	The firewall policy number that matched this traffic. A value of 0 means no explicit numbered policy matched, either because it is genuinely being handled by an internal, automatically indexed rule, or because the packet never reached the policy engine at all (more on that below).
`policytype`	Almost always policy for standard firewall policies; other values appear for local-in policies, DoS policies, and similar special cases.
`poluuid`	The policy’s UUID. Fortinet assigns a UUID to every policy so it can be tracked consistently even if the policy is renumbered or reordered.
`service`	The matched entry from Policy & Objects > Services, or a raw port number if no named service matched.
`action`	What the FortiGate did with the session: accept/close family values for allowed and normally terminated sessions, deny for anything blocked, start for the initial log of a session when start-of-session logging is enabled, and timeout for sessions closed due to inactivity.
`duration`	Session length in seconds. Zero means the session never actually established.
`sentbyte` / `rcvdbyte`	Bytes sent and received over the life of the session.
`sentpkt` / `rcvdpkt`	Packets sent and received.
`trandisp`	NAT disposition for the session. Covered in detail in the next section.
`msg`	A free text explanation of why the log was generated. For denies, this is often the single most useful field in the entire line, as it is in our captured log.

NAT Translation Fields

FortiOS uses two completely different pairs of fields depending on which direction the NAT happened, and mixing them up is one of the more common misreadings of a FortiGate log.

trandisp value	Meaning
`noop`	No NAT was applied to this session. This is what our captured log shows, which makes sense: the session was denied before any translation could take place.
`snat`	Source NAT was applied, most commonly outbound internet access through a policy with NAT enabled.
`dnat`	Destination NAT was applied, most commonly inbound access to a VIP.

Field	Applies when	Meaning
`transip`	`trandisp=snat`	The translated (post-NAT) source IP address.
`transport`	`trandisp=snat`	The translated (post-NAT) source port.
`tranip`	`trandisp=dnat`	The translated (post-NAT) destination IP address, i.e. the real internal server behind a VIP.
`tranport`	`trandisp=dnat`	The translated (post-NAT) destination port.

The naming is subtle on purpose: transip/transport (with the extra “s”) track source NAT, while tranip/tranport track destination NAT. If you are writing a log parser or a SIEM field mapping, get this pair backwards and every DNAT’d session will silently map to the wrong field.

Application and UTM Correlation Fields

These fields appear once Application Control, or any UTM profile, has visibility into the session.

Field	Meaning
`app`	The identified application signature, for example HTTPS.BROWSER or DNS.
`appid`	The numeric ID behind that application signature.
`appcat`	The application’s category, for example Web.Client or Network.Service. Sessions that never got deep enough for application identification show unscanned, which is what our captured log shows, consistent with the session being denied before any inspection happened.
`apprisk`	FortiGuard’s assigned risk level for the application (low, medium, elevated, high, and so on).
`applist`	The name of the Application Control profile that was applied.
`utmaction`	The action a UTM profile took on the session, independent of the firewall policy’s own action.
`utmref`	A reference ID tying this traffic log entry to a corresponding UTM log entry with more detail.
`countapp`	The number of distinct Application Control log entries associated with this one session.

Client Reputation and Device Identity Fields

FortiOS fingerprints devices and, when Client Reputation is enabled, scores their behavior over time. These fields ride along on Traffic logs once that visibility is available.

Field	Meaning
`devtype`	The FortiGate’s OS/device fingerprint for the source, for example Windows PC or Linux PC.
`devcategory`	A broader device category bucket, for example Windows Device.
`osname`	The specific operating system version detected for the source.
`srcmac`	The source’s MAC address. If there is a Layer 3 hop between the FortiGate and the actual client, this will be the next hop’s MAC, not the true endpoint’s.
`mastersrcmac`	The MAC address FortiOS considers the primary identity for a host that presents multiple network interfaces or MACs (common on client OSes with several NICs).
`srcserver`	Whether the source is flagged as a known server (1) or not (0).
`craction`	A bitmask representing which Client Reputation triggers fired for this session.
`crscore`	The numeric Client Reputation score contribution from this session.
`crlevel`	The Client Reputation severity bucket (low, medium, high, critical) this session’s score falls into.

Wireless and FortiAP Correlation Fields

When the source interface is a FortiAP managed SSID, FortiOS attaches wireless telemetry directly to the Traffic log, which is exactly what makes our captured log worth this level of attention.

Field	Meaning
`srcssid`	The SSID name the client associated with.
`ap`	The friendly name assigned to the FortiAP handling the client.
`apsn`	The FortiAP’s serial number, distinct from ap, which is just the display name.
`channel`	The wireless channel the AP radio was operating on at the time. Channels in the 100 to 144 range on 5 GHz require DFS (Dynamic Frequency Selection) because they overlap weather radar bands.
`radioband`	The radio mode and band in use, for example 802.11ac (5G).
`signal`	Received signal strength (RSSI) in dBm. Closer to zero is stronger; anything better than about -65 dBm is generally considered a solid connection.
`snr`	Signal to noise ratio in dB. Higher is better; values above roughly 25 dB are considered clean.

Field-by-Field Decode of the Captured Log

Now that every category has been covered, here is the actual log, read start to finish.

logver=0706063652: schema version added by the collector.

idseq=236394707511410688: unique log sequence ID assigned by the collector.

itime=2026-09-08 18:19:53: the collector received this log one second after the event itself occurred (time=18:19:52 below), which is a completely normal delay.

reporting_ip=10.250.59.214: the management IP of whatever forwarded this log to the collector.

devid=FG6H1ETB20902601: serial number of the reporting FortiGate.

vd=root: no VDOMs in use, or this is the root VDOM.

date=2026-09-08 / time=18:19:52: when the FortiGate itself recorded the event.

eventtime=1788905987031836316: the same moment, in nanosecond epoch time.

tz=-0400: the FortiGate is configured for Eastern Daylight Time.

logid=0000000007: this specific message ID. Log IDs in the 000000000x range are among the oldest and most common traffic message IDs in FortiOS, generally tied to deny events.

type=traffic / subtype=forward: a Traffic log, forward path, meaning this was traffic attempting to pass through the firewall between interfaces (not FortiGate-originated, not multicast, not a sniffer capture).

level=warning: moderate severity, consistent with a policy-level deny rather than a system fault.

srcip=10.1.105.32 / srcport=51120: the wireless client and its ephemeral source port.

srcintf=FDZ-OFF / srcintfrole=lan: the client associated to the SSID named FDZ-OFF, which is configured with a lan interface role.

srcssid=FDZ-OFF: confirms the SSID name directly (FortiOS commonly names the virtual WLAN interface after the SSID itself, which is why this matches srcintf).

apsn=PU431F5E19000557 / ap=FORTIAP-02: the physical AP handling this client is named FORTIAP-02, serial PU431F5E19000557.

channel=149: a 5 GHz UNII-2 Extended channel.

radioband=802.11ac (5G): the client was on the 5 GHz radio, running 802.11ac.

signal=-48 / snr=41: this is an excellent wireless link. -48 dBm and 41 dB SNR both indicate the client was close to the AP with a clean signal. This is the detail that rules out “bad WiFi” as the cause of this deny.

dstip=192.184.68.254 / dstport=443: the client was trying to reach an HTTPS destination on the public internet.

dstintf=unknown-0 / dstintfrole=undefined: no egress interface was ever resolved. This is a strong signal that the deny happened before the FortiGate got as far as a routing or policy lookup.

srccountry=Reserved: expected, since the source is a private RFC 1918 address.

dstcountry=United States: geolocation of the destination IP.

proto=6: TCP.

action=deny / policyid=0 / policytype=policy: denied, with no numbered policy attached.

service=HTTPS: matched service based on destination port 443.

trandisp=noop: no NAT was performed, consistent with the session never reaching the NAT stage.

appcat=unscanned: no application identification took place, again consistent with an early deny.

duration=0 / sentbyte=0 / rcvdbyte=0 / sentpkt=0 / rcvdpkt=0: nothing was actually forwarded. This was not a session that started and then got cut off; it never started at all.

msg=no session matched: the actual reason for the deny, and the field that ties the whole story together.

Put together: this was not a firewall policy explicitly blocking the destination, and it was not a wireless problem. msg=no session matched combined with an unresolved dstintf means the FortiGate’s session lookup rejected an out of state packet before routing or policy evaluation ever ran. In practice this shows up when a client roams between AP radios or reconnects mid flow and the return or continuation packets arrive without a live session table entry behind them, when a session aged out of the state table while a stray packet for it was still in flight, or, less commonly, when asymmetric routing means the FortiGate never saw the packet that would have created the session in the first place. Given the flawless signal and SNR here, a roam or a stale/expired session is the far more likely explanation than anything wireless.

The Four Traffic Subtypes, Compared

Subtype	Typical trigger	Notable field behavior
`forward`	Client-to-client or client-to-internet traffic through a firewall policy	Full field set: both interfaces resolved, NAT fields populated when applicable, application and UTM fields populated once inspection engages
`local`	Traffic to or from the FortiGate itself: admin access, DNS/NTP lookups it makes, RADIUS/LDAP queries, routing protocol traffic	Same core fields, but policyid=0 is normal here since local-in traffic is matched against implicit local-in rules rather than numbered firewall policies
`multicast`	Traffic matched against a multicast policy, typically PIM/IGMP driven	dstip is a multicast group address; policy comes from config firewall multicast-policy rather than the standard policy table
`sniffer`	A one-arm sniffer interface passively observing traffic	No real dstintf, since sniffer mode never forwards traffic, only watches it; no NAT fields, since nothing is actually being translated

Quick Reference Cheat Sheet

Category	Fields
Collector/header	logver, idseq, itime, reporting_ip, devid, devname, vd, date, time, eventtime, tz, logid, type, subtype, level, dtime
Five-tuple and policy	srcip, srcport, dstip, dstport, srcintf, dstintf, srcintfrole, dstintfrole, srccountry, dstcountry, proto, sessionid, policyid, policytype, poluuid, service, action, duration, sentbyte, rcvdbyte, sentpkt, rcvdpkt, trandisp, msg
NAT	transip, transport, tranip, tranport
Application/UTM	app, appid, appcat, apprisk, applist, utmaction, utmref, countapp
Client reputation/device	devtype, devcategory, osname, srcmac, mastersrcmac, srcserver, craction, crscore, crlevel
Wireless/FortiAP	srcssid, ap, apsn, channel, radioband, signal, snr

Wrap-Up

The intimidating part of a raw FortiGate log is never the number of fields, it is the lack of grouping. Once you sort them into header, five-tuple, NAT, application, client reputation, and wireless buckets, a 40-field log line reads in about the same time it takes to read a sentence. The next time you see action=deny with a policyid=0, check msg and dstintf before you assume it was a firewall rule doing its job. Sometimes it was, and sometimes, like here, the real story is a session table that never got a chance to open. If you are troubleshooting an active outage, start with msg and policyid together; they will tell you within seconds whether you are looking at a policy decision or a session state issue.

Decoding Every Field in a FortiGate Traffic Log: The Complete Reference

Executive Summary

The Log We Are Decoding

How FortiOS Organizes Its Logs

Universal Header Fields

Core Traffic Fields: The Five-Tuple, Policy Match, and Session Accounting

NAT Translation Fields

Application and UTM Correlation Fields

Client Reputation and Device Identity Fields

Wireless and FortiAP Correlation Fields

Field-by-Field Decode of the Captured Log

The Four Traffic Subtypes, Compared

Quick Reference Cheat Sheet

Wrap-Up

Recent posts