FortiGate troubleshooting becomes much faster when logging and diagnostics are designed before an outage. A device can generate traffic logs, security-event logs, system logs, authentication records, routing events, VPN messages, and detailed diagnostic output, but volume alone is not observability. Useful evidence has to answer a question: what decision did the firewall make, what did the packet look like, which object or policy was involved, and what changed before the failure appeared?<\/p>\n
Current FortiOS 7.6 operations also sit inside the post-July-2026 structure of Fortinet NSE certifications<\/a>. For administrators, that means product knowledge should be built around durable operating methods rather than older certification labels. Logging, session inspection, packet capture, and debug flow remain core techniques because they expose the path from observed symptom to firewall decision.<\/p>\n Start by listing the investigations the environment routinely performs. Security teams may need to prove which internal host contacted a destination, which user authenticated, which policy allowed a session, or which security profile blocked content. Network teams may need to know why a route changed or why a VPN dropped. Compliance teams may need retention and administrative-change records. Each question implies a log source, fields, timestamp quality, retention period, and destination.<\/p>\n This is better than turning on every possible message and hoping search will solve the problem later. Excessive low-value logging consumes storage, indexing resources, and analyst attention. Too little logging creates blind spots that become obvious only after an incident. The target is purposeful coverage: log the events needed to reconstruct important decisions, preserve the fields required for correlation, and retain them long enough for the investigations the organization actually performs.<\/p>\n For firewall traffic, a useful record includes source and destination information, ports and protocol, interfaces, action, policy identity, bytes, duration, and translation context when applicable. User identity and application information can make the same record more meaningful. When analysts can move from an alert to a policy ID and then to the exact rule that handled the session, troubleshooting becomes a controlled investigation rather than a search across screenshots.<\/p>\n Logging choices on firewall policies matter. If important traffic is not logged, the absence of records should not be interpreted as proof that the traffic never existed. Conversely, a log entry that shows an allowed session does not prove the application succeeded after the firewall forwarded it. Traffic logs reveal the FortiGate decision and session characteristics; application health may require server logs or packet evidence as well. Good operators know what each source can and cannot prove.<\/p>\n Correlation breaks quickly when clocks disagree. A FortiGate event at 10:03, an identity-provider event at 10:01, and a server event at 10:06 may describe the same user action, but analysts will struggle if timestamps are not synchronized or time zones are not understood. NTP configuration, consistent time-zone handling, and monitoring for clock drift are therefore security controls as much as administrative hygiene.<\/p>\n Time quality becomes even more important when logs are forwarded to FortiAnalyzer or another central system. The central platform can organize and search data, but it cannot retroactively make an incorrect device timestamp trustworthy. During incident response, record the time basis used by each source and correct for known offsets. During normal operations, treat clock-health alarms seriously enough that they are fixed before an event demands minute-by-minute reconstruction.<\/p>\n Sending logs to FortiAnalyzer can centralize search, event handling, reports, and longer-term analysis, but the forwarding design should still be explicit. Confirm that the expected log categories arrive, that the correct devices and ADOMs own the data, and that storage and retention align with investigation needs. A green connection status is not the same as proof that every required event is being received and indexed.<\/p>\nDesign logs around questions the operations team must answer<\/h2>\n
Traffic logging should preserve the policy and session context<\/h2>\n
Time synchronization is part of the logging architecture<\/h2>\n
FortiAnalyzer adds value when forwarding and storage are intentional<\/h2>\n