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.
The converter maps FortiGate traffic-log fields into these IPFIX-style biflow columns:
It uses these FortiGate fields when present:
Fortinet’s log reference documents these fields on forward traffic logs, including `eventtime`, `duration`, `sessionid`, `sentbyte`, `rcvdbyte`, `sentpkt`, `rcvdpkt`, `app`, `appcat`, `applist`, and `saasname`.
Sources:
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.
Fortinet documents that policy logging is controlled by the `Log Allowed Traffic` setting. For accepted traffic, the key choices are:
For AI-session capture, `All Sessions` is the safer choice because it gives you complete allowed-session logging, not just security-profile hits.
Fortinet also notes that all security-profile-related logs are tracked within the Traffic logs, so forward traffic can be searched in one place.
Sources:
On FortiGate hardware logging, Fortinet documents these relevant modes:
For biflow conversion, `per-session-ending` is often the better default because it produces fewer records and still includes the duration needed to infer session start time. If you need both start and end visibility, use `per-session`.
Sources:
Fortinet documents that Application Control can recognize a large number of applications and that you attach an application sensor to a firewall policy. This requires the FortiGuard Application Control subscription.
The most useful pattern for AI observability is:
1. Create or edit an Application Control sensor.
2. Add category filters or application overrides for AI applications you care about.
3. Use `Monitor` where you want visibility without blocking.
4. Attach that sensor to the firewall policy handling outbound web and AI traffic.
Fortinet explicitly states that `Monitor` passes the traffic and generates a log message, while `Allow` passes the traffic but does not generate a log message.
Sources:
Fortinet documents that deep inspection decrypts, inspects, and re-encrypts encrypted traffic. This is important for browser-based AI tools and many AI APIs because app identification and domain visibility are often weaker without decryption.
If you cannot decrypt everything, you can still capture useful session metrics from Traffic logs, but application labeling may be less reliable.
Sources:
Fortinet documents that FortiGate can store logs locally or send them to:
Fortinet also documents that syslog can be sent in `CSV` and `CEF` formats, and up to four syslog servers can be configured.
Sources:
CLI examples from Fortinet documentation:
config log fortianalyzer setting
set status enable
set server <server_IP>
set upload option realtime
end
config log syslogd setting
set status enable
set server <syslog_IP>
end
For a practical deployment:
1. Create a dedicated outbound policy for sanctioned AI and SaaS access where possible.
2. Set `Log Allowed Traffic` to `All Sessions` on that policy.
3. Attach an Application Control sensor using `Monitor` for the AI applications or categories you want observed.
4. Attach SSL/SSH inspection, preferably deep inspection where your policy allows it.
5. Send logs to FortiAnalyzer or syslog in real time.
This gives you the best chance of capturing `app`, `appcat`, `applist`, `saasname`, user, policy, and directional byte counters in one place.
The converter looks first at these FortiGate fields:
If your logs include recognizable AI app names or SaaS names, detection is more reliable. If the application field is generic, the converter falls back to URL and hostname-style clues.
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, not just AI sessions:
python .\fortigate_ai_to_ipfix.py .\fortigate.log --include-non-ai