FortiGate troubleshooting becomes much faster when you stop treating every connectivity failure as a firewall-policy problem. A packet can fail before policy evaluation because it never arrives, after routing because the wrong egress path is chosen, during policy lookup because no rule matches, during NAT because the translated address is wrong, or after forwarding because the return traffic follows a different path. FortiGate gives you two complementary tools for locating that failure: the packet sniffer shows what packets are present on interfaces, while debug flow explains how FortiOS processes selected traffic through the forwarding path.

The current NSE 4 FortiOS 7.6 Administrator scope explicitly includes diagnosing connectivity with packet captures and debug flow. The operational skill is not memorizing a long command sequence. It is knowing which evidence each tool can prove, narrowing the flow enough to avoid noise, and correlating packet evidence with routes, policies, sessions, NAT, and security inspection.

Start with a traffic hypothesis, not a command

Before opening a CLI session, define one failing conversation as precisely as possible: source IP, destination IP, protocol, source or destination port, expected ingress interface, and expected egress interface. A vague statement such as “the application is down” is not enough because a FortiGate may handle thousands of unrelated sessions at the same time. A narrow hypothesis lets you filter captures and debug output to the traffic that matters.

Also establish whether the failure affects all users, one subnet, one destination, one protocol, or one direction. If every connection through one WAN link fails, the cause may be routing or interface state. If only HTTPS to one server fails, policy, VIP, SSL inspection, or the server itself becomes more plausible. If new sessions fail but established sessions continue, session state, policy changes, or upstream reachability may matter more than physical connectivity.

This discipline mirrors ordinary packet analysis. Wireshark packet-sniffing skills transfer directly because a FortiGate capture still requires you to read source and destination addresses, flags, retransmissions, and request/response direction instead of treating the capture as a decorative log.

The packet sniffer proves whether traffic reaches an interface

The built-in packet sniffer is the fastest way to answer the most basic questions: does the request enter the FortiGate, does it leave, and does a reply come back? Capture on the expected ingress interface first. If the client sends packets but the FortiGate never sees them, debugging FortiOS policy is premature. Investigate the access switch, VLAN, ARP/neighbor resolution, upstream route, client gateway, or physical path instead.

If the request enters and a translated or forwarded packet leaves, move attention downstream. If the request leaves but no reply returns, the remote host, intermediate routing, security controls, or asymmetric path may be responsible. If both directions are visible at the expected interfaces but the application still fails, inspect transport behavior, security profiles, TLS, DNS, or application-layer errors.

Packet captures are especially useful around NAT. The same connection may appear with private source addresses on one side and translated addresses on the other. Comparing ingress and egress captures lets you verify that FortiGate is performing the transformation you intended. This becomes critical when multiple IP pools, VIPs, central NAT rules, or overlapping networks are involved.

Debug flow explains the FortiOS forwarding decision

Fortinet documents debug flow as a way to trace packets when traffic does not enter and leave FortiGate as expected. Filters can be applied by source, destination, port, and protocol, and the trace is then started for the selected traffic. The output can show route lookup, policy evaluation, session creation, NAT decisions, and the reason a packet is denied or accepted.

That makes debug flow more interpretive than a raw capture. A packet sniffer might prove that a SYN arrived, but debug flow can show that no matching policy was found or that the packet matched a different policy than expected. It can also reveal that a route lookup selected an unexpected interface or gateway. When a policy looks correct in the GUI but traffic still fails, this evidence is far stronger than visually re-reading the policy list.

Debug output must be filtered tightly. Running an unrestricted flow trace on a busy firewall can generate overwhelming output and consume troubleshooting attention. Filter one source and destination pair where possible, limit the number of traces, reproduce the problem once, and stop debugging when you have the evidence you need.

Understand sessions before assuming a new policy will apply

FortiGate is stateful. Once a session exists, later packets normally follow the existing session state rather than repeating the entire first-packet decision process. This is why a policy or NAT change can appear ineffective for a connection that was already established. Troubleshooting should determine whether the test is creating a new session and whether an old session is preserving earlier decisions.

Session inspection also helps explain asymmetric failures. If FortiGate sees the initial traffic but the return path bypasses the same stateful firewall, the expected session may never complete correctly. Multi-WAN routing, SD-WAN, policy routes, ECMP, upstream load balancers, and cloud routing can all create paths that look valid individually but violate stateful symmetry.

Do not clear large session tables casually in production. If a session must be removed to retest a corrected policy or NAT rule, target the affected conversation or schedule the action with awareness of user impact. Troubleshooting should reduce uncertainty without creating a second outage.

Use debug flow to distinguish routing, policy, and NAT failures

A practical layered method is to check routing first, then policy, then translation. Confirm that FortiGate has a usable route to the destination and that the route points toward the intended egress interface. If route selection is wrong, changing the firewall policy will not fix the forwarding decision. Next, verify which policy ID actually matches the traffic rather than assuming the visually closest rule wins.

Only after the route and policy are understood should you validate SNAT or DNAT behavior. For outbound traffic, confirm the expected source address or IP pool. For inbound publishing, confirm that the VIP or central DNAT object maps the public destination to the correct internal host and that the resulting traffic still matches an allow policy. NAT can make troubleshooting confusing because the address visible on one side of the firewall is not necessarily the address used for policy or routing decisions at every stage.

If the packet is accepted and forwarded correctly but the application fails, stop changing the firewall merely because it is in the path. Capture the server response, verify the return route, and examine higher-layer dependencies. A good firewall troubleshooter knows when the evidence points away from the firewall.

Hardware offload and inspection can change what you observe

FortiGate platforms can offload eligible traffic to network processors. Hardware acceleration is desirable in production, but it can make some software-path debugging less intuitive because not every packet traverses the CPU in the same way as a non-offloaded flow. When a trace seems incomplete, consider whether acceleration is relevant and use Fortinet’s documented diagnostic approach for the platform and software release.

Security inspection adds another layer. Antivirus, IPS, application control, web filtering, or SSL inspection may allow the firewall policy but still reset, block, or alter the application session. In that case, traffic logs and security logs become as important as debug flow. The distinction is simple: policy acceptance answers whether the connection is allowed into the inspection path; security profiles can still decide what happens to the content.

Fortinet certification objectives connect these layers because FortiOS administration is not just rule creation; it is interpreting routing, state, translation, identity, and inspection as one forwarding system.

A repeatable troubleshooting sequence reduces guesswork

For a new incident, begin with interface status and a specific test flow. Capture on ingress to prove arrival. Check routing for the destination. Run a filtered debug flow to identify the route, matching policy, session, and NAT decision. Capture on egress to confirm what FortiGate actually transmits. Then check for the return packet and verify that it comes back through a path compatible with the session.

If the session is permitted but the application still fails, inspect security-profile logs, DNS behavior, TLS negotiation, MTU, and the server response. If the failure changes after a configuration update, verify that you are testing a fresh session. Document the working and failing packet path before making multiple simultaneous changes.

This workflow prevents the most common troubleshooting mistake: changing several firewall settings until traffic happens to work. Debug flow and packet sniffer are valuable because they replace intuition with evidence. Used together, they show both what was on the wire and why FortiOS made the forwarding decision it did.

In production, capture evidence before applying a fix whenever practical. A small packet trace, the relevant route, the matched policy ID, and the session/NAT result create a useful incident record. That record helps peers review the conclusion, makes recurring problems easier to recognize, and reduces the temptation to rely on memory when the same symptom returns months later.

Build captures that another engineer can reproduce

Operational troubleshooting improves when the capture method is repeatable. Record the filter, interface, test source, destination, protocol, timestamp, and whether the trace was taken before or after NAT. A five-line note can save another engineer from repeating the same discovery work and makes packet evidence usable in a change or incident review.

Capture duration matters as much as filter syntax. Start the capture immediately before reproducing the issue and stop it as soon as the relevant exchange completes. Long captures create noise, consume storage if exported, and make it harder to align a packet with the corresponding traffic and security logs. For intermittent failures, use a narrow filter and a longer observation window rather than an unrestricted capture.

When troubleshooting TCP, follow the handshake and teardown. A SYN without a SYN-ACK points to a different class of failure than a completed handshake followed by an application reset. Repeated retransmissions suggest loss or an unreachable return path. For UDP, there may be no handshake, so compare expected requests and replies and use application knowledge to decide what response should exist.

Correlate clocks across client, FortiGate, server, and monitoring systems. If device time is inconsistent, a packet capture and a security log may look unrelated even when they describe the same session. Accurate time also matters when a FortiAnalyzer or SIEM is used to reconstruct the event after the fact.