FortiGate NAT: Follow the Packet, Not the Checkbox
NAT problems become confusing when translation is treated as a checkbox instead of a change to packet identity. A FortiGate can translate a source before traffic leaves an interface, publish an internal service through destination translation, select addresses from an IP pool, or participate in designs where central NAT separates translation rules from firewall policy. Each option changes what later devices see and what return traffic must match.
NAT scenarios in the current FortiOS 7.6 Administrator exam reward an understanding of ordinary firewall operation rather than isolated controls. NAT fits that goal because the correct answer in a troubleshooting scenario depends on packet direction, policy, routing, session state, and the address values visible on each side of the firewall.
The Fortinet certification path extends those ideas into more complex secure-networking roles, but the foundation remains simple: write down the original packet, identify where translation occurs, and then write down the packet that the next device receives.
That method is faster than guessing because most NAT incidents are not mysterious. They are mismatches between what one component expects and the address or port that another component actually sees.
Source NAT changes the identity presented to the destination
When source NAT is enabled for outbound traffic, the destination usually does not see the client’s original private address. It sees an address chosen by the FortiGate configuration, such as the outgoing interface address or an address from an IP pool. That translated identity affects upstream ACLs, application logging, rate limits, partner allowlists, and return routing.
Before changing NAT, confirm what identity the far side is supposed to see. If a SaaS provider has allowlisted a specific public range, using the interface address instead of the intended pool can break access even though routing and policy are otherwise correct. The firewall may report an allowed session while the remote service rejects the translated source.
Destination NAT changes how published services are reached
Publishing an internal service usually requires translating an address or service seen on the external side to the internal destination. The troubleshooting question is whether the client is reaching the correct public address, whether FortiGate translates it as intended, and whether the internal server can return through a path that preserves the session.
Server teams often troubleshoot only the internal address, while network teams look only at the public one. A useful incident record includes both. It should show the address and port before translation, the address and port after translation, and the firewall policy associated with that path.
Policy NAT and central NAT require different reading habits
FortiGate can place NAT decisions directly in policy or use a central NAT model depending on operating mode and design. Administrators who move between environments can make mistakes when they assume translation is expressed in the same location everywhere.
The safest approach is to identify the active NAT model before interpreting the configuration. In a policy-NAT design, firewall policy and translation may be closely coupled. In a central-NAT design, the administrator must trace policy and translation separately. The packet still follows one coherent path, but the configuration objects expressing that path are different.
IP pools make outbound identity deliberate
An IP pool lets the organization control which translated addresses represent outbound sessions. That can support partner allowlists, tenant separation, service-specific egress identities, or address conservation. It also introduces another object that must be validated during troubleshooting.
Check whether the correct pool is selected, whether addresses are available, and whether the upstream network routes replies for those public addresses back to the FortiGate. A perfectly configured pool cannot solve a routing problem outside the firewall.
Port translation creates another layer of state
Many-to-one source NAT depends on translating source ports so many internal connections can share a smaller number of public addresses. That behavior is usually invisible to users, but it becomes relevant when troubleshooting applications with unusual session behavior, upstream devices that track source ports, or environments approaching translation scale limits.
Packet captures should therefore include ports as well as addresses. Saying that “the IP is correct” is incomplete if the application depends on a specific service mapping or the translated port is part of the failure.
Routing still decides where translated traffic can go
NAT does not replace routing. The FortiGate still needs a valid route for the destination and a usable path out of the selected interface or SD-WAN member. Likewise, the remote side needs a route that returns traffic to the translated source address.
This is why one-way traffic is such a useful clue. If the initial packet leaves with the expected translation but no response returns, investigate the far-side route, upstream filtering, or application behavior before rewriting the firewall rule. A NAT configuration can be correct while the surrounding network is incomplete.
Sessions are the bridge between forward and return translation
FortiGate tracks state so return traffic can be associated with the original conversation and reverse translation can occur. The session table is therefore one of the best places to confirm what translation was actually applied, rather than relying only on what the policy appears to specify.
Existing sessions can also survive configuration changes long enough to mislead testing. When validating a NAT change, make sure the test creates a new connection or clear the relevant state carefully. Otherwise the old session may continue using the previous translation and make a correct change look ineffective.
NAT should not become a substitute for clean addressing or policy
Translation is useful, but it can also hide architecture problems. Stacking unnecessary NAT layers makes logs harder to correlate, complicates application allowlists, and creates more places where troubleshooting must translate between identities. Use NAT because the design requires it, not because it seems easier than fixing routing or address ownership.
The same operational principle appears in firewall administration work: policy clarity matters because future operators must understand the rule base under pressure. A NAT design that only its original author can explain is fragile even if it functions today.
A NAT incident should end with a before-and-after packet story
The strongest troubleshooting record states the original source and destination, the ingress interface, the matched policy, the translation applied, the egress interface, and the return behavior. That sequence makes it possible to separate firewall translation from routing, server, or upstream network failures.
It also makes validation repeatable. After the fix, run the same flow and confirm that the packet identity at every observation point matches the design. If the organization uses monitoring or partner allowlists, verify those systems see the intended translated source rather than only confirming that one client session succeeds.
NAT stops being mysterious when administrators stop reasoning from labels and start reasoning from packets. FortiGate is changing specific fields in a stateful flow. Once those changes are written down explicitly, most translation problems become ordinary path-analysis problems with much clearer evidence.
Hairpin or internal-to-published-service traffic is a useful test of whether the addressing model is understood. Internal users may try to reach the same public name used by external clients, causing the flow to enter translation and routing logic differently from a purely external connection. If internal DNS returns the public address, the firewall design must intentionally support that path or provide split-name resolution. Otherwise the service can work from the internet while failing from inside the network.
Overlapping address spaces create a more difficult NAT use case. Mergers, partner VPNs, labs, and cloud networks sometimes reuse the same private subnets. Translation can make those networks communicate, but the design must be symmetric and well documented because operators can no longer reason from original addresses alone. Logs and diagrams should show both native and translated networks so incident responders know which identity applies at each boundary.
Application protocols can also carry address information inside their payloads or open related connections. Stateful helpers or application-aware gateways may be needed for some legacy protocols, while modern applications usually avoid these assumptions. When a basic TCP test succeeds but the full application fails, inspect whether the protocol creates secondary flows or embeds addressing that NAT changes cannot transparently repair.
Vendor-neutral routing knowledge remains useful here. The addressing and path-selection foundations covered by Network+ N10-009 help explain why NAT cannot compensate for a missing route or an incorrect default gateway. FortiGate adds platform-specific translation controls, but the packet still depends on ordinary IP forwarding before and after the address rewrite.
Change review should consider every consumer of translated identity. Security analytics, web servers, partner systems, rate-limit engines, and audit tools may all record the post-NAT address. Moving from interface NAT to an IP pool can therefore fix one connectivity requirement while breaking correlation elsewhere. A safe NAT change includes both connectivity testing and confirmation that downstream systems still interpret the source correctly.
Logging should make translation visible enough to correlate both sides of the conversation. When possible, preserve original and translated addresses, policy identifiers, and session timing in the evidence sent to central monitoring. This becomes critical during security investigations because an analyst may receive an external alert about a public IP and need to map it back to the internal host that owned the translated session at that moment.
NAT designs should also have a capacity assumption. Large numbers of concurrent sessions, constrained IP pools, or port-heavy applications can create scale limits that do not appear in a simple connectivity test. Capacity monitoring should track session growth and translated-address usage so exhaustion is detected before users experience intermittent failures that look random.
That same packet-first discipline should be reflected in diagrams, so translated and untranslated addresses are both visible to operators.