Fortinet NSE4_FGT_AD-7.6: FortiGate Central SNAT vs Policy NAT

FortiGate can perform source NAT in more than one operational style. In the familiar policy-NAT model, SNAT is configured directly on the IPv4 firewall policy by enabling NAT and optionally selecting an IP pool. In central SNAT mode, source translation is moved into the separate central-snat-map table, while the firewall policy continues to decide whether the traffic is allowed. The choice changes where administrators look for translation logic and how finely they can match it.

Fortinet’s current FortiOS 7.6 guidance states that central NAT is not enabled by default. When central NAT is enabled, the NAT option under IPv4 policies is skipped and SNAT is configured through the central SNAT table. Central SNAT rules are evaluated top-down and are applied after the security policy, allowing matches on interfaces, source and destination addresses, protocol, ports, and IP pools.

This distinction is foundational to Network Security Platforms.

Understand policy NAT first

With central NAT disabled, a FortiGate IPv4 firewall policy can enable NAT directly.

The administrator can use the outgoing interface address or an IP pool according to the policy’s needs.

FortiGate NAT is easiest to troubleshoot when you follow the packet and know which object performs translation instead of treating NAT as one checkbox.

Central SNAT separates allow from translation

When central NAT is enabled, the firewall policy handles security policy matching while the central SNAT table handles source translation.

This separation can make large environments easier to reason about when NAT policy changes on different dimensions from security policy.

It also means administrators must remember to inspect both tables when a session is allowed but the source address is not translated as expected.

Central SNAT adds more match dimensions

Central SNAT entries can match incoming interface, outgoing interface, source, destination, protocol, destination port, original source port, and other supported fields.

An IP pool can then define the translated source address, with explicit port mapping available in supported scenarios.

This granularity can reduce the need to duplicate firewall rules simply because two flows need different source translation.

Rule order matters

FortiGate reads central SNAT rules from the top down until it finds a match.

Specific exceptions should therefore appear before broad catch-all translation rules.

Firewall policy design should keep ordering understandable enough that administrators can predict which rule will win without scanning a large ambiguous table during an outage.

Central SNAT is applied after security policy

Fortinet documents central SNAT as being applied after a security policy has matched the session.

This is an important troubleshooting distinction: the traffic first needs a permitting security policy, then the central SNAT rule determines source translation.

FortiGate sessions can show the actual translated addresses and help confirm whether policy and NAT both matched as expected.

Use IP pools deliberately

Both policy NAT and central SNAT can use IP pools for translated source addresses.

Choose pool type, overload behavior, port preservation, and any explicit mapping according to the upstream network and application requirement.

A translation design should also account for reverse routing and any provider or partner allowlist that expects a specific public source address.

Know the NGFW policy-based-mode behavior

Fortinet notes that when NGFW mode is policy-based, central NAT—specifically central SNAT—is assumed to be enabled implicitly.

Administrators moving between profile-based and policy-based modes should understand that NAT placement can therefore differ from a familiar policy-NAT configuration.

Do not troubleshoot a missing policy NAT checkbox as though the feature disappeared; check the operating mode and central SNAT table.

Plan transitions carefully

Switching an established firewall to central NAT changes the configuration model and troubleshooting workflow.

Inventory existing NAT-enabled policies and IP pools, reproduce required translations in the central table, validate rule order, and test representative sessions before a broad cutover.

FortiGate troubleshooting should include route, policy, NAT, session, and return path rather than changing several controls at once.

Choose by scale and operating model

Policy NAT is direct and easy to understand for smaller environments where translation naturally follows the security policy.

Central SNAT is valuable when translation requires independent ordering, destination-aware matching, port-specific behavior, shared IP pools, or centralized NAT governance.

For Fortinet practitioners, the durable rule is simple: know which mode is active, remember that central SNAT is a separate top-down translation table applied after policy, and troubleshoot from the actual session rather than from the GUI location where you expected NAT to be configured.

Central NAT also affects DNAT workflow. Fortinet documents that VIP handling changes when central NAT is enabled: destination translation objects exist separately and are not selected in the firewall policy in the same way as non-central NAT mode. Administrators should therefore treat a move to central NAT as a broader NAT architecture change, not only an SNAT reorganization.

Central SNAT supports IPv4 and IPv6 policy entries, and FortiOS 7.6 also documents NAT46/NAT64 support in the modern NAT object model. These capabilities matter in mixed-address environments, but they add another reason to document the active NAT mode and rule type clearly before troubleshooting.

Logging and session inspection should confirm the chosen design. Verify original and translated addresses, policy ID, route, interfaces, and IP pool behavior with diagnostic tools. If the session never forms, fix routing or security policy first; if the session forms with the wrong source, then inspect central-SNAT ordering and matching.

The best choice is the one the operations team can understand consistently. Central SNAT can provide cleaner translation policy at scale, while policy NAT can be simpler for straightforward firewalls. Mixing mental models is what causes confusion—so document the mode, rule ownership, and troubleshooting sequence as part of the firewall standard.

Migration testing should include asymmetric routing. SNAT changes the source address that upstream devices see, which can alter return routes, firewall rules, partner allowlists, and SD-WAN behavior. Test both forward and return traffic after moving a translation from policy NAT to central SNAT so a successful outbound packet is not mistaken for a healthy session.

Central SNAT rule specificity should be documented. A broad top rule matching all internal sources can shadow later rules intended for one application or partner. Use comments and naming that state business intent, and review the table top to bottom after every major change. Translation tables become difficult to operate when the only documentation is an address-object name.

IP pool selection affects troubleshooting. Overload, one-to-one, port block allocation, and other pool behaviors can change how many internal sessions share a public address and how ports are chosen. Operations teams should know which pool type is expected for each central rule and which logs or session fields confirm the actual allocation.

Central SNAT can be useful in large multi-zone or multi-tenant environments because translation can be managed independently from security policy. This can avoid duplicating nearly identical firewall policies only to select different public pools. The benefit is strongest when NAT ownership and security-policy ownership are documented and coordinated.

Policy NAT can still be the better choice when the environment is small and each firewall policy naturally owns its translation. Keeping the NAT decision next to the allow rule can make reviews and changes faster. Centralization is not automatically superior; it trades local simplicity for centralized control and richer matching.

Change control should include rollback of the NAT mode itself. Switching central NAT can affect GUI options, VIP usage, and how administrators expect translation to be configured. Capture the previous configuration, schedule a test window, and verify representative inbound and outbound sessions before considering the migration complete.

For managed FortiGate estates, FortiManager policy packages should preserve the same central-NAT mental model. Administrators need to know whether the ADOM/package enables central NAT, how rule order is managed, and where translation is reviewed. Centralized management is helpful only when the operational team can trace the generated device configuration back to the policy object.

Diagnostics should follow FortiGate’s actual packet-processing path. Confirm route lookup, policy match, central SNAT match, session creation, IP-pool allocation, and return path in that order. This avoids editing translation rules when the real problem is that the traffic never matched the intended firewall policy or selected a different egress interface.

High availability should also be considered. SNAT state and IP-pool behavior must remain consistent enough across an HA pair that failover does not create unexpected public-source changes or session disruption beyond the designed behavior. Test critical translated applications through failover rather than assuming configuration synchronization alone proves the design.

For audited environments, central SNAT can improve separation of duties because translation policy can be reviewed as its own ordered table. That benefit only exists if rule ownership, change approval, comments, and logging are maintained. A central table with hundreds of undocumented entries can be harder to govern than policy NAT.

Policy reviews should include both the permitting rule and translation rule when central SNAT is used. A change ticket that reviews only the firewall policy can miss a central-SNAT entry that routes the session through an unexpected public address. Link related policy and NAT objects in documentation or comments where operations tooling allows it.

For environments with many IP pools, maintain a source-of-truth map from public addresses to applications, partners, and central-SNAT rules. This simplifies incident response when an external party reports suspicious traffic from one public IP and the firewall team must identify which internal flows could have used it.

Central SNAT earns its complexity when it makes translation policy clearer at scale. If administrators still need to duplicate rules, rely on undocumented order, or inspect several unrelated objects to understand one flow, revisit the design instead of assuming centralization itself is the solution.