When traffic breaks on a Fortinet firewall, the hard part is usually not finding a symptom. Users already know something is down. The hard part is finding where the failure starts. A good troubleshooter does not jump between random screens or guess at fixes. They follow the packet. They confirm what the firewall saw, which policy matched, whether NAT changed the flow, and why the session was allowed, denied, or dropped later by inspection or routing. This cheat sheet is built for that exact job. It gives you a practical triage workflow for Fortinet NSE 6 Network Security 7.6 support work, with the log fields that matter most, the policy and NAT mistakes that cause real outages, and the fastest ways to verify a fix. If you are preparing for support scenarios, the Fortinet NSE 6 Network Security 7.6 Support Engineer practice test can help you get used to the logic behind these checks. Use this article as a working reference, and turn the final checklist into a printable desk-side guide.
Start with a simple triage workflow
The best troubleshooting flow is boring on purpose. It reduces missed steps. When traffic fails, move through these checks in order:
- Define the exact traffic. Source IP, destination IP, protocol, port, time of failure, and whether the issue is one-way or both ways.
- Confirm the path reaches the firewall. If the firewall never sees the packet, no policy review will help.
- Check the forward traffic log. Look for policy ID, action, NAT result, interfaces, and security profile outcome.
- Verify routing. A correct policy cannot fix a missing route or wrong egress interface.
- Verify policy match and sequence. FortiGate stops at the first matching policy. A broad deny or a narrower policy above the expected one often causes surprises.
- Check NAT. Source NAT and destination NAT change addresses and can break return traffic, server reachability, and policy matching.
- Check session state. Existing sessions may keep old policy or route decisions until they age out or are cleared.
- Check security inspection. If traffic was allowed by policy but reset later, an SSL, web, application, IPS, or DNS profile may be the true cause.
- Retest and verify in logs. Never stop at “it should work now.” Confirm a successful log entry and application behavior.
This order matters because each layer depends on the one before it. For example, if the route points traffic out the wrong interface, you may still see a matching policy, but the session will fail after that point.
Identify the problem clearly before opening logs
Many support cases drag on because the original symptom was too vague. “The site is not working” is not enough. You need details that let you search logs and compare expected versus actual behavior.
Collect these first:
- Client IP and, if possible, client subnet
- Server IP or FQDN
- Application or service, such as HTTPS, RDP, SMTP, or VPN
- Port and protocol
- Time of the last failure
- Direction: inbound, outbound, inter-VLAN, or VPN-to-LAN
- Impact scope: one host, one subnet, or all users
- Recent changes: policy edits, route changes, NAT changes, firmware upgrades, certificate updates
Why this matters: a single host failing often points to endpoint settings, local routing, ARP, or stale sessions. A whole subnet failing usually points to policy, routing, interface status, or NAT. A single application failing while ping works often points to ports, inspection, or asymmetric return traffic.
Know the log fields that explain most traffic failures
Fortinet logs contain a lot of data, but only a small set consistently explains why traffic failed. In forward traffic logs, focus on these fields first:
- Source and destination address – Verify the firewall saw the same IPs you expected. NAT may change what appears in later stages.
- Source and destination interface – Confirms ingress and egress path. If the egress interface is wrong, check routing.
- Service / port / protocol – Makes sure the traffic matched the expected service object.
- Action – Accept, deny, timeout, server-rst, client-rst, or other outcomes. “Accept” only means the policy allowed it. It does not guarantee the application succeeded.
- Policy ID – One of the most important fields. It tells you exactly which policy matched.
- NAT translated source or destination – Shows whether source NAT or VIP translation occurred.
- Sent and received bytes – Very useful for one-way traffic. For example, many bytes sent but almost none received may suggest return-path issues.
- Session duration – A session that dies immediately often points to resets, denial, or missing return traffic.
- Security profile result – Web filter, IPS, application control, SSL inspection, antivirus, and DNS filter can all block after policy acceptance.
- Reason / subtype – Tells you whether the event was a policy deny, local-in issue, profile block, or system event.
A useful habit is to read the log in this order: who talked to whom, through which interfaces, matched which policy, with which NAT, and what happened next. That sequence mirrors the firewall decision process.
How to read allow versus deny correctly
One common mistake is assuming that an allow log means the firewall is no longer part of the problem. That is not always true.
If the log shows deny, start with policy match, zones or interfaces, addresses, service objects, schedule, and policy order.
If the log shows accept but the app still fails, think about these causes:
- Return traffic is broken because of routing, NAT, or asymmetry.
- Security inspection blocked later, such as SSL inspection certificate issues or IPS resets.
- Server refused the connection, which can appear as a server reset.
- Policy matched, but the wrong policy matched. The broad policy may allow traffic without the needed NAT or profile settings.
- DNS resolution failed even though raw IP traffic is allowed.
Example: users cannot browse to a web app. Logs show action accept on HTTPS. Policy ID is correct. But byte count is tiny and the server sends resets. That points away from simple policy denial and toward certificate mismatch, TLS inspection, or an application-side refusal.
Policy mistakes that cause real outages
Most traffic issues on FortiGate come down to a short list of policy problems. These are the ones worth checking every time.
- Wrong policy order. FortiGate uses first match. A broader rule above a specific one can steal traffic.
- Wrong source or destination object. Subnet masks are a classic trap. A /24 and /25 look similar in a hurry, but they behave very differently.
- Wrong service object. Custom services with incorrect destination port ranges can silently miss the traffic.
- Schedule mismatch. Time-based policies fail outside the allowed window.
- Policy exists on the wrong interface pair. The addresses may be correct, but the traffic enters or exits through different interfaces than expected.
- Disabled policy. Simple, but easy to miss in change-heavy environments.
- Implicit deny hit. If no policy matches, traffic is dropped by default.
Why policy order matters so much: the firewall does not keep looking for a “better” match. Once one policy matches source, destination, service, schedule, and interfaces, evaluation stops. That means a generic allow rule may accidentally bypass a more specific policy with required inspection or NAT. The reverse is also true. A narrow deny rule placed too high can block traffic you expected to be allowed lower down.
NAT pitfalls that break traffic in subtle ways
NAT problems are often harder to spot than policy problems because traffic may partially work. A session may establish, then fail on the return path or inside the application.
Watch for these common NAT issues:
- Missing source NAT for internet-bound traffic. Private addresses leave the firewall, but the return traffic never comes back correctly.
- Unexpected source NAT. Internal traffic gets NATed when it should not, and the destination server sees the wrong client IP.
- VIP configured, but policy does not reference the translated destination correctly. The packet reaches the firewall, but the expected inbound translation path is not used.
- Overlapping VIPs or address objects. Traffic hits a different translation than the one you intended.
- Port forwarding mismatch. The external port and internal mapped port are not aligned with the server service.
- Hairpin NAT issues. Internal users trying to reach an internal server via its public IP often need specific handling.
- Central NAT versus policy NAT confusion. If the environment uses central NAT, changing only the firewall policy may not change the translation result.
Example: an internal server is published through a VIP. External users can connect, but internal users using the public DNS name cannot. The policy looks fine. The likely issue is hairpin traffic, not basic policy denial.
Routing and asymmetry checks you should do early
If a policy looks correct but sessions still fail, routing is the next place to look. A firewall can allow a packet and still send it out the wrong path.
Check these routing conditions:
- Does the destination route exist? No route means no clean forward path.
- Is the next hop reachable? A route on paper is useless if the next hop is down or unresolved.
- Is the selected egress interface the one your policy expects? Interface mismatch can break policy matching and return traffic.
- Are there overlapping routes? A more specific route may pull traffic away from the expected path.
- Is SD-WAN steering changing the path? Traffic may leave through a member you did not expect.
- Is return traffic coming back through another firewall or interface? Asymmetric paths can break sessions and inspection.
A strong clue for asymmetry is uneven byte counts or repeated session setup attempts with no stable application flow. In many cases, the SYN leaves correctly, but the SYN-ACK returns somewhere else.
When security profiles are the real problem
Traffic can match the right policy and still fail because a profile blocks it after the basic allow decision. This is why “policy says allow” is not the end of troubleshooting.
Profiles worth checking:
- SSL inspection – Certificate trust problems, unsupported ciphers, pinned certificates, or deep inspection limits can break HTTPS.
- Web filter – Category blocks or rating errors can stop web access even with an allow policy.
- Application control – Specific apps may be blocked while the port remains open.
- IPS – False positives or strict signatures can reset sessions.
- DNS filter – Name resolution fails, so users think “the site is down” when the issue is DNS blocking.
- Antivirus / content inspection – File downloads may fail while the site itself loads.
The reason this matters in support cases is that users report the application symptom, not the network control that caused it. “Email attachments won’t open” may actually be a profile action against downloads, not an SMTP problem.
Verification steps after you make a change
Good engineers do not stop after changing a policy or route. They verify from multiple angles.
- Generate fresh traffic. Ask the user to retry, or test from a known host.
- Check for a new forward traffic log. Do not rely on old entries.
- Confirm the correct policy ID now matches.
- Confirm the NAT result is what you intended.
- Check byte counts both directions. Healthy sessions usually show balanced movement for interactive apps.
- Confirm the route and egress interface are correct.
- Clear stale sessions if needed. Existing sessions may keep old decisions.
- Retest the actual application, not just ping. Ping success does not prove HTTPS, RDP, or SIP will work.
This verification step prevents false wins. A change can fix one piece and still leave the application broken for another reason.
Printable troubleshooting checklist
Use this as a quick desk reference during live triage:
- 1. Define traffic: source, destination, service, time, direction, scope.
- 2. Confirm the firewall saw it: traffic log or packet capture path check.
- 3. Read the log: interfaces, policy ID, action, NAT, bytes, profile result.
- 4. If denied: check policy order, objects, service, schedule, interface pair, implicit deny.
- 5. If accepted but failing: check route, return path, NAT, profile actions, server resets.
- 6. Check NAT: source NAT, VIP, central NAT, port mapping, hairpin cases.
- 7. Check routing: route existence, next hop, SD-WAN path, asymmetry.
- 8. Check inspection: SSL, web filter, app control, IPS, DNS filter, AV.
- 9. Clear stale sessions if needed.
- 10. Retest and verify with new logs.
What separates fast troubleshooting from random troubleshooting
Fast Fortinet support work is not about memorizing every feature. It is about following a disciplined sequence and knowing which evidence matters. Logs tell you what the firewall saw. Policy ID tells you which rule actually won. NAT tells you whether addresses changed in a way that affects return traffic. Routing tells you where the packet went next. Inspection tells you whether the flow was blocked after initial acceptance. Once you read those pieces together, most traffic issues become much less mysterious.
If you want one habit to keep, make it this: always trace the real packet path instead of troubleshooting from the config alone. Configs show intent. Logs and session behavior show reality. In Fortinet environments, that difference is often where the answer lives.
