Fortigate GW & FW collected session logs

Fortigate AI Session Logging Guide

Upload

Input

Output

This guide covers:

1. How to capture Fortinet FortiGate traffic logs with enough detail to convert them into IPFIX biflow-style session data.
2. How to configure FortiGate logging and security profiles so AI-related sessions are visible and exportable.

The companion converter is: fortigate_ai_to_ipfix.py

What the converter expects

The converter maps FortiGate traffic-log fields into these IPFIX-style biflow columns:

• flowStartMilliseconds
• flowEndMilliseconds
• sourceIPv4Address
• destinationIPv4Address
• sourceTransportPort
• destinationTransportPort
• protocolIdentifier
• packetDeltaCount
• octetDeltaCount
• reversePacketDeltaCount
• reverseOctetDeltaCount

It uses these FortiGate fields when present:

• eventtime
• duration
• srcip, dstip
• srcport, dstport
• proto
• sentbyte, rcvdbyte
• sentpkt, rcvdpkt
• sessionid
• app, appcat, apprisk
• applist
• saasname
• srcuser
• policyname, policyid

Fortinet’s log reference documents these fields on forward traffic logs, including eventtime, duration, sessionid, sentbyte, rcvdbyte, sentpkt, rcvdpkt, app, appcat, applist, and saasname.

Recommended capture model

For AI observability on FortiGate, the cleanest path is:

1. Enable traffic logging on the policies that allow outbound SaaS and AI traffic.
2. Set policy logging to capture all sessions where you need session-level byte and packet visibility.
3. Attach Application Control to those same policies.
4. Use SSL inspection if you need visibility into encrypted AI applications and domains.
5. Forward logs to FortiAnalyzer, FortiGate Cloud, or syslog in a structured format.
6. Export the logs and feed them to the converter.

1. Enable policy traffic logging

Fortinet documents that policy logging is controlled by the Log Allowed Traffic setting.

For accepted traffic, the key choices are:

• Security Events
• All Sessions

For AI-session capture, All Sessions is the safer choice because it gives complete allowed-session logging instead of only security-profile hits.

Fortinet also notes that all security-profile-related logs are tracked within the Traffic logs.

2. Choose per-session or per-session-ending deliberately

FortiGate supports these logging modes:

• per-session – two log messages per session, one at establishment and one at the end
• per-session-ending – one log message at the end, including session duration

For biflow conversion, per-session-ending is often the better default because it produces fewer records while still including the duration needed to infer session start time.

If you need both start and end visibility, use per-session.

3. Enable Application Control for AI app identification

Application Control can recognize a large number of applications and requires an Application Control sensor attached to the firewall policy.

Recommended AI observability pattern:

1. Create or edit an Application Control sensor.
2. Add category filters or application overrides for AI applications.
3. Use Monitor where visibility is needed without blocking.
4. Attach the sensor to outbound web and AI traffic policies.

Fortinet states that Monitor passes the traffic and generates a log message, while Allow passes the traffic without generating a log message.

4. Use SSL inspection when AI traffic is encrypted

Deep inspection decrypts, inspects, and re-encrypts encrypted traffic.

This is important for browser-based AI tools and AI APIs because application identification and domain visibility are weaker without decryption.

If full decryption is not possible, Traffic logs still provide useful session metrics, but application labeling may be less reliable.

5. Configure log targets

FortiGate can store logs locally or send them to:

• FortiAnalyzer
• FortiAnalyzer Cloud
• FortiGate Cloud
• Syslog servers

Syslog can be exported in CSV and CEF formats.

CLI example for FortiAnalyzer:

config log fortianalyzer setting
    set status enable
    set server <server_IP>
    set upload option realtime
end

CLI example for syslog:

config log syslogd setting
    set status enable
    set server <syslog_IP>
end

6. Suggested FortiGate policy pattern for AI-session capture

Recommended deployment model:

1. Create a dedicated outbound policy for sanctioned AI and SaaS access.
2. Set Log Allowed Traffic to All Sessions.
3. Attach an Application Control sensor using Monitor.
4. Attach SSL/SSH inspection, preferably deep inspection.
5. Send logs to FortiAnalyzer or syslog in real time.

This helps capture app, appcat, applist, saasname, user, policy, and directional byte counters together.

7. Fields that help identify AI sessions

The converter primarily looks at:

• app
• appcat
• applist
• saasname
• hostname
• url
• domain

If logs contain recognizable AI app names or SaaS names, detection becomes more reliable.

If the application field is generic, the converter falls back to URL and hostname clues.

Running the converter

FortiGate raw key-value syslog:

python .\fortigate_ai_to_ipfix.py .\fortigate.log

FortiGate JSON export:

python .\fortigate_ai_to_ipfix.py .\fortigate.json

Add extra AI keywords:

python .\fortigate_ai_to_ipfix.py .\fortigate.log --keyword "vertex ai" --keyword "azure-openai"

Keep all traffic sessions:

python .\fortigate_ai_to_ipfix.py .\fortigate.log --include-non-ai

Important limitations

• All Sessions logging produces more volume than Security Events.
• per-session-ending is usually enough for biflow analytics but does not provide a distinct session-start log.
• Application identification for encrypted AI traffic is better with SSL inspection.
• If logs do not contain app, appcat, saasname, or host/domain context, AI classification becomes weaker.