FortiGate NAT: Policy, Translation, and Troubleshooting

Network address translation on a FortiGate is easy to describe and surprisingly easy to misdiagnose. A packet may be allowed by the correct firewall policy and still fail because the wrong source address is presented upstream, a virtual IP does not match the arriving traffic, or return routing sends the session through a different path. The useful way to think about NAT is therefore not as an isolated checkbox. It is one stage in a complete traffic decision that includes routing, policy lookup, translation, session state, and the behavior of the device on the other side.

That perspective matters even more in current Fortinet environments. Since the July 2026 certification-program change, FortiGate and FortiOS Administrator knowledge maps into NSE 4, while the wider structure of Fortinet NSE certifications now uses the restored NSE 1–8 levels. The product mechanics have not become less important because the certification labels changed. Administrators still need to predict exactly which address a peer will see, which rule will match, and how the return packet will be associated with the original session.

Start with the traffic identity you actually need

The best NAT design begins with a plain-language statement of the desired identity. For outbound client traffic, ask whether many private hosts should share the outgoing interface address, whether a defined public pool is required, or whether a particular internal system must keep a predictable translated address. For inbound publishing, ask which public address and service should represent the internal server and whether the external port should differ from the internal port. These are different problems, even though both are called NAT.

That distinction prevents a common configuration failure: using an available NAT mechanism simply because it looks familiar. Interface-address source NAT is convenient for ordinary internet access, but it is a poor fit when downstream systems must recognize stable public addresses. A virtual IP is appropriate for destination translation, but it does not replace the security policy that permits the translated flow. Central SNAT can provide a clear translation table, but it also creates another ordered policy set that operations teams must understand. The right choice is the one that makes the intended packet identity obvious to the next administrator.

Source NAT is a policy about the address the outside world sees

Source NAT changes the source identity of an outbound flow. In a basic branch deployment, a firewall policy can translate many private client addresses to the egress interface address. This is simple and often exactly what is required. The design becomes more deliberate when public IP pools are introduced. Pools make it possible to separate traffic by business service, tenant, application, or reputation boundary, and they can preserve a stable external identity even when the private topology changes.

Port translation is part of the same design. Many internal sessions can share a smaller number of public addresses because source ports distinguish the translations. That efficiency also creates operational limits: a very large number of sessions can exhaust a translation pool or make forensic correlation harder if logs do not retain the pre- and post-NAT tuple. When stable one-to-one behavior is required, the pool and translation method should reflect that requirement. Treat the public address as an operational dependency, not merely as an implementation detail.

Central SNAT changes where administrators look for the decision

FortiOS can use central SNAT policies so that source translation is controlled in a dedicated ordered table rather than being configured only within each firewall policy. This is valuable in environments where address translation needs its own ownership, where multiple security policies share the same translation logic, or where translation needs to be reviewed independently of application access. The benefit is separation of concerns; the cost is that troubleshooting now requires awareness of two policy decisions instead of one.

Order matters. A broad central SNAT rule placed above a more specific rule can produce a technically valid translation that is operationally wrong. The symptom may appear upstream as an unexpected source IP, a partner allow-list failure, or traffic arriving from an address with the wrong reputation. A disciplined design uses narrow matching conditions, meaningful comments, and a review process that considers the central SNAT table alongside firewall-policy changes. When central SNAT is enabled, checking only the firewall policy is an incomplete investigation.

Destination NAT and virtual IPs publish services without moving them

Destination NAT solves the opposite problem: an external client addresses a public endpoint, while the protected service lives on a different internal address. FortiGate virtual IP objects provide this mapping and can also perform port forwarding. That makes it possible, for example, to expose a public TCP port while sending the session to a different internal port. The virtual IP becomes part of the firewall policy so that the system can both translate the destination and enforce access to the resulting flow.

Publishing a service safely requires more than a working mapping. The policy should restrict sources when possible, apply the relevant inspection profiles, and log enough information to reconstruct the session. The server’s default gateway or return path must also make sense. A perfectly configured inbound translation can still fail if the server replies through another router and bypasses the FortiGate that owns the session. When public services are multi-homed or load-balanced, return-path design should be reviewed before anyone blames the virtual IP itself.

Routing and policy lookup determine whether NAT ever gets a chance

NAT cannot rescue a broken routing or policy decision. Before focusing on translation, confirm that the FortiGate has a usable route to the destination and that the incoming and outgoing interfaces place the flow in the expected policy context. For outbound access, verify the selected egress path and then the firewall policy and source translation. For inbound publishing, verify that the public address reaches the FortiGate, the virtual IP matches the packet, the resulting policy permits the translated destination, and the internal route is valid.

This sequence matters because symptoms are deceptive. A browser timeout may look like a NAT problem when the real issue is DNS, upstream routing, a missing security policy, or an application that is not listening. Conversely, a policy hit counter can increase while the peer rejects traffic because the translated source is wrong. The investigation should follow the packet rather than the GUI screen. Ask what the packet looks like at each boundary and what decision the FortiGate makes next.

Session state explains why a correct change may not appear to work immediately

FortiGate is a stateful firewall, so a session records the decisions made when the flow was created. If an administrator changes an IP pool, a route, or a policy while an existing session is active, the old session can continue to reflect earlier state. This is why configuration review and session review belong together. A troubleshooting test should make clear whether it uses a fresh connection or an established flow, especially when validating a NAT change.

Asymmetric paths create another state problem. When one side of a conversation enters through one FortiGate or interface and the response returns through another path, the device handling the reply may lack the expected session context. In HA, SD-WAN, or multi-router designs, this can look like intermittent translation failure because only certain paths reproduce it. NAT troubleshooting therefore needs a topology view: source, destination, routing domains, failover behavior, and where session state is expected to live.

Use evidence to troubleshoot translation instead of changing random settings

A reliable investigation starts with a specific five-tuple: source IP, destination IP, source port, destination port, and protocol. Confirm the route, identify the matching firewall policy, identify the expected NAT rule, and then observe the actual flow. FortiGate packet-flow debugging can show policy and session decisions, while a targeted packet capture shows what entered and left an interface. The two views answer different questions and work best together.

Capture on both sides of the translation when practical. If the inside packet appears but the outside packet does not, focus on FortiGate policy, routing, and session decisions. If the outside packet has the wrong translated identity, focus on the source NAT rule or pool. If the outbound packet is correct and no response returns, the failure may be upstream. If the response returns but never reaches the original client, inspect session state, reverse translation, and internal routing. This evidence-first sequence is faster than repeatedly changing NAT options and hoping the symptom disappears.

Good NAT design leaves an audit trail that another operator can follow

Production NAT becomes difficult when public addresses are treated as anonymous plumbing. Maintain ownership for public pools and VIPs, document why a translation exists, and keep old objects from accumulating indefinitely. Logs should preserve enough pre-NAT and post-NAT context to support security investigations and partner disputes. Changes to widely shared NAT rules deserve the same review discipline as changes to routing or access control because one translation edit can affect many otherwise unrelated applications.

The practical skill is not memorizing every NAT knob. It is being able to explain the intended identity of the packet before and after the firewall, identify which FortiGate mechanism performs that translation, and prove the behavior with routing, session, and packet evidence. Once that mental model is solid, source NAT, central SNAT, virtual IPs, port forwarding, and troubleshooting become parts of one coherent traffic story rather than separate configuration topics.

One final design check is to compare configuration intent with the view seen by systems outside the firewall. Public SaaS providers, partner allow-lists, DNS records, and monitoring tools often encode assumptions about source or destination addresses. A NAT change can therefore be technically correct on FortiGate and still break a dependency nobody included in the firewall ticket. Before changing a shared pool or VIP, inventory those external dependencies, identify a validation owner, and define how the old mapping will be restored if downstream behavior changes. After implementation, verify a representative transaction from both directions and record the translated tuple in the change evidence. That simple before-and-after check turns NAT from an invisible side effect into a controlled part of the application architecture.