Troubleshooting is where the FortiOS 7.6 Administrator exam pulls the other domains together. The same evidence-first approach also appears in broader network troubleshooting, but FortiGate adds stateful policy, NAT, identity, inspection, VPN, and HA decisions to the path. A FortiGate problem can involve interface state, routing, policy, NAT, authentication, security profiles, VPN negotiation, HA behavior, or an application that is failing beyond the firewall. The challenge is rarely lack of available commands. It is knowing which hypothesis to test first and which evidence can eliminate the largest part of the problem space.
A disciplined method is more reliable than a memorized command list. Define the expected traffic path, find the first point where actual behavior differs, and move outward only after proving each stage. This keeps administrators from changing unrelated configuration while a simple route, policy, or identity mismatch remains unresolved.
Start with a precise symptom statement
Replace ‘the Internet is broken’ with a measurable statement: one subnet cannot reach one destination over one service, new sessions fail but existing sessions work, VPN negotiation succeeds but application traffic does not pass, or users authenticate but match the wrong policy. Precision immediately suggests which FortiGate subsystems matter and which can be ignored.
Record source IP, destination IP or name, protocol and port, time of failure, user identity if relevant, expected egress interface, and whether the behavior affects all clients or a subset. Troubleshooting accelerates when every test can be tied back to a specific expected path.
Prove Layer 1 and interface state before higher layers
An administratively down interface, failed link, VLAN mismatch, or physical error can create symptoms that look like routing or firewall-policy problems. Verify interface status, speed and duplex where relevant, VLAN tagging, and basic reachability to directly connected neighbors before debugging complex features.
The goal is not to follow the OSI model mechanically in every incident. It is to avoid spending twenty minutes on security profiles when the WAN interface is down. Evidence from interface state and counters can remove entire classes of explanations quickly.
Use the routing table to predict the egress path
Before looking at policy, determine where FortiGate intends to send the destination. Longest-prefix match, administrative distance, policy routes, SD-WAN rules, and dynamic routing can all influence forwarding. If the selected route is wrong, changing the firewall rule may simply permit traffic onto the wrong path.
A useful habit is to write down the expected ingress and egress interfaces before opening the policy table. FortiGate policies are interface-oriented, so incorrect path prediction often explains why a seemingly correct rule never matches.
Verify policy and NAT together
Once the path is known, identify the policy that should match. Confirm source, destination, service, schedule, identity conditions, and interface pair. Then verify NAT behavior. A rule can permit the traffic while an unexpected translation causes the remote application or return route to fail.
Policy order matters as much as policy contents. A broader rule can match earlier and apply a different profile or translation than the administrator expects. Traffic logs often expose this immediately by recording the actual policy ID that handled the session.
Use session state as a bridge between policy and packets
FortiGate is stateful, so the session table shows how the device understood an active flow. It can reveal original and translated addresses, selected policy, interfaces, and session state. This is especially useful when routing and policy appear correct but the return path or NAT behavior is uncertain.
If a configuration change is made during testing, remember that existing sessions may continue using old decisions until they expire or are cleared. A changed rule that appears ineffective may simply be bypassed by an established session. Distinguish configuration state from session state.
Move into feature-specific diagnostics only when justified
If ordinary forwarding is proven, then investigate the feature most closely tied to the symptom. For VPNs, inspect IKE and selectors. For identity, verify authentication and user mapping. For security profiles, inspect the profile logs and SSL visibility. For SD-WAN, verify health checks and rule selection. This preserves a narrow troubleshooting scope.
Feature-specific debug output can be extremely detailed. Turn it on with a hypothesis and a defined traffic sample, then stop it after collecting the needed evidence. Unlimited debug without filtering creates so much output that important events become harder to find.
Packet capture answers the final path question
Packet capture is valuable when you need to know whether a packet entered FortiGate, whether it left the expected interface, and whether a response returned. Capturing at multiple interfaces can prove exactly where traffic disappears. It is particularly effective for asymmetric routing, handshake failure, retransmissions, and protocols where the firewall logs show a permit but the application still fails.
Capture interpretation is easier if routing and policy were already checked. Otherwise, packet traces become another large dataset without a model. The best capture is not the longest; it is the one that tests a specific forwarding claim.
Avoid changing configuration until you can explain the failure
Blind changes destroy evidence and can introduce second-order problems. If a rule is widened, a route is added, and inspection is disabled at the same time, the service may recover but no one knows which change mattered. Make the smallest change that tests the current hypothesis, then validate both the intended service and unrelated traffic that could be affected.
This also improves rollback. A troubleshooting step that has one purpose and one expected result is easy to reverse. A collection of emergency edits made without a model is difficult to clean up after the outage.
Turn solved incidents into reusable operational knowledge
After restoration, record the symptom, root cause, evidence, fix, and validation. Repeated issues should become monitoring, configuration standards, or runbook checks. If the same failed route or certificate problem surprises the team every month, the organization has a knowledge-management problem as well as a technical one.
That operational mindset is useful across the Fortinet ecosystem. Products and commands change, but good administrators continuously convert incidents into better baselines, clearer alerts, and faster future diagnosis. The exam’s troubleshooting scenarios are practice for that real-world habit.
DNS deserves special attention because it can make network reachability look inconsistent. A user who can ping an address but cannot open the named service may have a name-resolution problem, split-DNS issue, or stale record rather than a firewall problem. Conversely, a correct DNS answer proves only that the name resolved; it does not prove the chosen address is reachable through the expected route and policy. Keep name resolution as its own checkpoint in the path.
Asymmetric routing is another common source of confusing stateful-firewall symptoms. If the forward path crosses one FortiGate but the reply returns through another device, the original firewall may never see the traffic required to complete session state. Packet captures on ingress and egress interfaces, together with route inspection on both ends, can reveal this quickly. Adding a permissive firewall rule will not fix a path that bypasses the stateful device on the return trip.
Resource exhaustion should be considered when failures are intermittent or load-dependent. High CPU, memory pressure, session-table saturation, or interface errors can cause symptoms that disappear during quiet periods. Compare the incident time with resource and session trends. A configuration can be logically correct and still fail operationally because the device is undersized or a traffic surge exposed a limit.
After a fix, validate both success and containment. Confirm the original flow now works, then verify that unrelated security boundaries remain intact. A troubleshooting change that restores service by bypassing inspection, widening a source network, or adding a broad route may create a silent security regression. The incident is not finished until the intended path works for the intended reason.
A strong troubleshooting note records negative evidence too. ‘Route is present, policy 27 matches, no NAT is applied, SYN leaves port2, no SYN-ACK returns’ is far more useful than ‘firewall checked.’ Negative evidence narrows ownership and makes escalation productive. It can show that the FortiGate forwarded correctly and that the next investigation belongs on the remote host, upstream router, or external service rather than on another firewall rule.
Name the expected policy, route, and translation before generating test traffic. Then compare the actual session with those expectations. This simple habit turns troubleshooting into a falsifiable exercise: if the packet uses a different policy, find out why; if it exits a different interface, inspect routing; if the translated address is unexpected, inspect NAT. Without an expected result, every command output can look plausible.
Be careful with cached state outside the firewall too. DNS caches, ARP tables, client routes, browser sessions, and upstream load balancers can preserve behavior after the FortiGate has been corrected. If the device now shows the expected path but the client still reports failure, clear or age out relevant state methodically rather than undoing a valid firewall fix.
Troubleshooting speed improves when baselines exist before incidents. Save normal routing tables, HA states, resource ranges, VPN status, and common traffic patterns. A baseline makes deviation obvious. Without it, an engineer may spend time debating whether 70 percent CPU, a route count, or a session volume is normal for that site. Operational knowledge is part of the toolset.
Continue exploring the technologies and certification concepts that matter most to you.