FortiGate troubleshooting is fastest when evidence is collected at the layer where the decision is being made. Traffic logs show sessions, event logs show system activity, security logs show inspection decisions, the routing table shows path selection, and packet or flow diagnostics show what happened to a specific packet. The Fortinet NSE4_FGT_AD-7.6 exam expects administrators to move between these sources methodically.
Logging also has an architectural role. Logs can be kept locally when capacity permits, forwarded to FortiAnalyzer, or sent to other collectors such as syslog platforms. The right design balances retention, searchability, storage, security, and the need to investigate events that happened long before anyone noticed a symptom.
The broader network engineering lesson is simple: a good diagnosis is built from observations, not from changing configuration until the problem disappears.
Traffic logs answer who talked to whom
Forward-traffic logs can show source and destination addresses, ports, protocol, policy, interfaces, action, byte counts, NAT information, and other session details depending on configuration. This is often the quickest way to confirm whether a connection reached FortiGate and which policy handled it.
Logging must be enabled at the required policy or feature level. If a policy is not configured to log the relevant sessions, an empty log search does not prove the traffic never occurred. Always distinguish “no event” from “no retained event.”
Use filters aggressively. A busy firewall can generate enormous volume, and a useful investigation usually begins with a narrow source, destination, policy, user, or time range rather than scanning everything.
Event logs explain changes in the firewall itself
System event logs capture administrative logins, configuration changes, interface events, HA transitions, routing-related events, and other control-plane activity. When a problem began at a precise time, event logs can reveal the configuration or state change that coincided with the symptom.
This is especially useful for intermittent incidents. A user may report that traffic failed for two minutes overnight. By the time an engineer checks the device, every interface is up. Event history can still reveal a link flap, HA failover, VPN renegotiation, or administrator change.
Time synchronization is essential. If firewalls, switches, servers, and monitoring platforms disagree about time, correlation becomes much harder. NTP is therefore part of incident-quality logging, not merely housekeeping.
Security logs explain inspection decisions
Antivirus, intrusion prevention, web filtering, DNS filtering, application control, and other profiles generate security events when they detect or block content. These records can identify the signature, category, application, file, or domain that caused a session to be changed or denied.
Correlate security events with the traffic log for the same session. A traffic log may show that the firewall policy accepted the flow, while a security event shows that IPS later reset it. Without that correlation, an administrator may incorrectly edit the firewall rule.
High-quality operations also distinguish policy enforcement from true security incidents. A blocked entertainment category and an exploit signature may both appear as security events, but they deserve different response workflows.
Centralized logging preserves history and improves analysis
FortiAnalyzer can receive and index Fortinet logs for centralized search, reporting, and event analysis. Generic syslog can integrate FortiGate with broader SIEM or operations tooling. Local logging can still be useful, but appliance storage and retention may be limited relative to a dedicated collector.
Choose retention based on investigation and compliance needs. A firewall that holds only a short window of logs may be unable to answer questions about a compromise discovered weeks later. Central collection also protects evidence when a device fails or is replaced.
Log transport and administrator access to the log platform should be secured. Centralizing sensitive network telemetry creates a valuable dataset that deserves its own availability and access-control design.
Routing and session diagnostics narrow the problem
Before running deep debug, inspect normal state. Check the routing table for the destination, interface status, ARP or neighbor information, and the session table for established flows. These low-impact checks often reveal the problem immediately.
Session diagnostics show how FortiGate has recorded an active connection, including interfaces, policy, state, and NAT details. If the session exists and increments traffic counters in both directions, the firewall is seeing more than a one-way attempt. If no session forms, focus earlier in the path.
Existing sessions can also preserve old decisions after a configuration change. When behavior differs from the current rule set, determine whether the test is reusing an established session.
Packet capture proves what reaches an interface
A packet sniffer is one of the most objective tools available. Capturing on the ingress interface proves whether the packet reaches FortiGate. Capturing on the egress interface proves whether it leaves. Comparing both sides helps separate upstream problems from firewall decisions.
Use capture filters to limit the scope. Capturing all traffic on a busy firewall creates too much data and can increase operational risk. Filter by host, port, protocol, or interface so the result answers a specific question.
Packet capture does not always explain why a packet was dropped. It shows presence, absence, and packet details. When the question becomes why FortiGate chose a route or policy, move to flow diagnostics.
Debug flow explains packet-processing decisions
FortiOS debug flow can trace packets through routing, policy, NAT, and other processing decisions. Filters should be applied before starting the trace so that the output remains focused. The goal is to capture the smallest amount of debug output that proves which decision was made.
Debugging is powerful and should be used carefully in production. Broad or long-running debug output can create noise and consume resources. Stop the debug when the required evidence has been captured and clear filters so the next investigation starts cleanly.
Read debug output as a sequence rather than searching only for a familiar error phrase. The packet may be rejected because no route exists, no policy matches, reverse-path validation fails, a session conflicts, or another feature changes the flow.
Build a repeatable diagnostic workflow
Start with the symptom and define one test flow. Record source, destination, port, time, and expected path. Check traffic logs. Verify route and policy. Inspect the session. Capture packets if needed. Use debug flow only when the earlier evidence leaves a decision unexplained.
Keep changes separate from observation. If you modify routes, policies, NAT, and security profiles before collecting evidence, you destroy the original state and may create a second problem. Diagnose first, then make the smallest justified change.
For the exam, the most valuable skill is choosing the right tool for the question. Logs explain history and policy outcomes; routing and sessions explain state; packet capture proves traffic presence; debug flow explains FortiGate’s processing path.
Good logs need context, retention, and integrity
Collecting logs is not enough if the records cannot answer operational questions. Include meaningful device names, policy names, user identity where available, synchronized timestamps, and consistent address objects so searches return understandable results. A numeric policy ID without documentation is less useful during an incident than a rule whose name identifies the business service.
Retention should match the time it takes the organization to discover problems. Security events are often investigated long after the original session ended, while capacity or performance investigations may need weeks of history to identify a trend. Storage planning should therefore consider both event volume and the desired investigation window.
Log integrity also matters. Access to centralized logs should be restricted, changes audited, and transport protected where supported. Evidence loses value if the same administrator who is being investigated can silently erase or alter it.
Diagnostics should have an escalation ladder
Use the least invasive tool that can answer the question. Start with dashboards, logs, routing tables, interface counters, and session state. Escalate to packet capture when you need to prove where traffic exists. Use debug flow or feature-specific debugging when you need FortiOS to explain a decision that normal state cannot reveal.
This ladder reduces risk on busy production systems. It also creates cleaner evidence because each step is driven by the previous result. The Fortinet exam path rewards the same discipline: know what information each tool provides and avoid turning every incident into a full-debug event.
Correlate network evidence with application evidence
Firewall logs rarely tell the entire story. Application servers, identity systems, DNS resolvers, endpoint clients, switches, and upstream providers may all hold pieces of the same incident. A failed HTTPS transaction might involve successful firewall forwarding followed by a TLS error on the server, while a failed login may involve correct network transport but a rejected identity assertion.
Correlating those sources requires common timestamps, consistent identifiers, and a clear test case. When possible, record the client address, destination, user, transaction time, and application error before beginning network analysis. This prevents the firewall team from spending hours proving connectivity for a failure that occurred after the packet successfully reached the application.
For recurring incidents, create a short capture plan before the next occurrence: define the log filters, packet-capture scope, responsible engineer, and retention location. Preparing the evidence path in advance turns an intermittent failure into a structured observation exercise instead of another round of guesswork.