Firewall policy is the center of FortiGate traffic processing. A FortiGate can know a route, own the correct address objects, and have working interfaces, yet traffic still fails if no policy permits the session. For the Fortinet NSE4_FGT_AD-7.6 exam, the key skill is not memorizing where every GUI checkbox sits. It is understanding how FortiOS decides which policy applies, how stateful sessions are created, and where source and destination NAT change the packet flow.
FortiOS 7.6 supports conventional policy-based source NAT, IP pools, virtual IPs for destination NAT, and an optional central SNAT table. These mechanisms solve different translation requirements. When candidates mix them together, troubleshooting becomes guesswork. When they keep routing, policy matching, session state, and translation as separate steps, complex scenarios become much easier to reason about.
This topic also belongs to the broader network engineering certification skill set because firewall administrators must understand addressing, routes, interfaces, and transport-layer services before they can write reliable security policy.
A policy describes a traffic path
A FortiGate firewall policy matches traffic using characteristics that include the incoming interface, outgoing interface, source, destination, schedule, and service. If the packet matches a policy, FortiOS applies the action and associated features. If no policy matches, the traffic is dropped. An explicit deny policy is useful when denied traffic must be logged or handled differently from the implicit default drop.
Policy order matters because more than one rule can appear relevant to an administrator reading the configuration. The practical question is which rule actually matches the packet as FortiOS evaluates the policy set. A broad allow rule placed too high can absorb traffic intended for a narrower rule. Conversely, an overly narrow object or wrong interface can prevent the intended policy from matching at all.
The exam-worthy habit is to describe the actual five-tuple and path before inspecting policy: source IP and port, destination IP and port, protocol, ingress interface, and expected egress. If those values are vague, policy troubleshooting will also be vague.
Routing and policy matching are connected
FortiGate policy matching is not independent from routing. The firewall needs to know the outgoing interface for routed traffic, and the existence of the required route can affect which policy is eligible. That is why a policy that appears correct in the GUI may never match when the routing table sends the packet somewhere else.
This is especially important when administrators create overlapping static routes, dynamic routes, SD-WAN zones, or policy routes. The policy should describe the path that FortiOS will actually use, not the path the administrator intended in a diagram. Verifying the routing decision first often saves time.
A disciplined workflow checks interface state and addressing, then routing, then policy match, then NAT, then security inspection. Jumping directly to the firewall rule without confirming the route can lead to unnecessary policy changes that never solve the underlying problem.
Source NAT changes the identity seen downstream
Source NAT replaces the source address of outbound traffic. A common configuration uses the outgoing interface address, but IP pools allow sessions to use one or more defined addresses instead. This is useful when different internal systems need distinct public identities, when large-scale address translation requires multiple addresses, or when policy design needs explicit control over the translated source.
Dynamic SNAT with IP pools can use overload behavior so many internal sessions share one or more external addresses with port translation. The design question is not merely whether NAT is enabled. It is which translated address should be used, how many concurrent sessions must be supported, and whether downstream systems depend on a stable source identity.
In the normal policy NAT model, NAT settings are associated with the firewall policy. If central NAT is enabled, FortiOS uses the central SNAT table instead and the policy NAT control is not the place to define source translation. Mixing assumptions from these two modes is a frequent source of confusion.
Central SNAT separates translation policy from security policy
Central SNAT provides a dedicated rule table for source translation. Rules can match source, destination, protocol or port characteristics and select an IP pool. FortiGate evaluates those central NAT rules in order, which makes ordering just as important as firewall policy ordering.
The separation can be useful in larger designs because security policy and translation logic can evolve independently. A security rule can express which traffic is permitted, while the central SNAT table expresses how permitted traffic should appear on the outside. That separation can also make troubleshooting harder if an administrator expects all NAT settings to live inside the security rule.
Whenever central NAT is enabled, document it clearly. A troubleshooting engineer should not have to discover halfway through an outage that policy NAT settings are being ignored because translation has been centralized elsewhere.
Destination NAT uses virtual IPs
Destination NAT commonly publishes an internal service through a virtual IP, or VIP. The VIP represents the translated destination mapping, while the firewall policy determines which source traffic is allowed to use that published service. NAT alone does not create authorization; the policy remains the security boundary.
Think carefully about the packet before and after translation. An external client sends traffic to a public address and port. FortiGate matches the relevant VIP and policy, then forwards the session toward the internal destination. Return traffic must follow a compatible path so the stateful session and reverse translation can succeed.
VIPs also affect policy matching behavior, which is why deny rules around published services deserve extra attention. When the design calls for blocking specific sources to a service exposed through a VIP, the deny policy must be written so that it actually matches the VIP-bound traffic rather than a different destination representation.
Stateful sessions explain many surprises
FortiGate is stateful. Once a session is established, subsequent packets are usually handled according to the session state instead of being treated as unrelated first packets. This matters during testing. An administrator can change policy or NAT and then wonder why an existing connection still behaves according to the earlier decision.
Session state also explains reverse traffic. FortiGate knows the translation and policy context associated with an established flow, allowing return packets to be handled consistently. When asymmetric routing sends one direction through a different firewall or path, that state can be missing and the session may fail even though each one-way route looks plausible.
When troubleshooting after policy changes, consider whether old sessions should be cleared in a controlled way before drawing conclusions. Do not clear large portions of the session table casually in production because the action can interrupt unrelated users.
Security profiles come after basic policy success
An allow policy can also attach inspection features such as antivirus, web filtering, DNS filtering, application control, intrusion prevention, and SSL inspection. These features add security value, but they also add another layer that can block or modify traffic after the basic policy matches.
A good troubleshooting method first proves that routing, policy, and NAT are correct, then checks the attached security profiles. If a website is reachable when inspection is removed but fails when a particular profile is applied, the investigation has moved from basic reachability to content or application inspection.
This layered approach is safer than making several changes at once. It preserves the original design and helps identify exactly which control caused the behavior.
A reliable policy-and-NAT troubleshooting sequence
Start with the packet path. Confirm the ingress interface, source, destination, protocol, and expected egress. Verify the route. Use policy matching or flow diagnostics to identify the rule. Check whether NAT is policy-based or centralized. Confirm the translated source or destination. Then examine sessions and security profiles.
Tools such as policy match, routing-table inspection, session diagnostics, packet capture, and debug flow provide evidence at different stages. The administrator should use the least disruptive tool that answers the current question. A packet sniffer proves whether traffic reaches an interface; debug flow can reveal route and policy decisions; session output shows how FortiGate is tracking an established connection.
For certification preparation, practice explaining why a packet is accepted, denied, or translated. That reasoning is more durable than memorizing a single lab. It also aligns with the way real FortiGate incidents are solved.
Policy design should survive growth
A small firewall can begin with a handful of rules and still become difficult to manage if object naming, comments, policy grouping, and change ownership are inconsistent. Build address and service objects around stable business meaning rather than around one temporary incident. A rule named for a system or application is easier to review than one composed of anonymous IP literals that no one recognizes six months later.
Policy review should also look for shadowed rules, overly broad services, unused objects, and old NAT mappings that no longer represent live applications. Across Fortinet certifications, that operational discipline matters, but it begins with a clean FortiGate rule base that makes troubleshooting and audit evidence easier to interpret. A useful review traces the matched source and destination, service, address translation, inspection profile and logging behavior before changing production traffic.