FortiGate Central NAT separates network translation from individual firewall policies. When central NAT is enabled, source NAT is configured in the Central SNAT table instead of through the NAT setting inside each IPv4 policy, and destination NAT uses virtual IP objects managed outside the firewall rule. This can make large environments easier to govern because translation rules have their own ordered policy, but it also changes the troubleshooting sequence.
Within Fortinet Security Operations, central NAT is a configuration-model decision. A session is permitted by one rule set and translated by another, so operators need to know which rule matched at both layers.
The existing NAT and PAT design constraints article provides the broader translation model; this page focuses on how FortiGate represents it in central NAT mode.
Central SNAT is disabled by default
Current FortiOS 8.0 documentation states that central SNAT is not enabled by default in ordinary profile-based policy mode.
Once enabled, the NAT option under IPv4 firewall policies is skipped and source translation must be defined through the central-snat-map table.
This means migration should include every policy currently performing source NAT, not just rules that use special IP pools.
Central SNAT rules are ordered top to bottom
FortiGate evaluates central SNAT entries from the top until a matching rule is found.
Rules can match incoming/outgoing interface, source/destination address, source port, protocol, and use specific pools or translation behavior.
Ordering therefore matters. A broad early rule can shadow a narrow rule below it even though the firewall security policy match is correct.
Security policy is evaluated before central SNAT
FortiOS documentation notes that central SNAT is applied after the security policy.
During troubleshooting, first verify the session is allowed by the intended firewall rule, then inspect the central SNAT rule that determines the translated source.
This prevents teams from editing NAT because a session failed when the real issue is security-policy or routing selection.
Central DNAT keeps VIPs outside the firewall rule
When central NAT is enabled, VIPs used for destination NAT are configured as separate objects and are not assigned directly in the firewall policy in the same way as non-central NAT mode.
The VIP must be enabled and the policy must allow the resulting destination flow according to the central-NAT processing model.
Operators should therefore review both VIP state and policy state when an inbound service is unreachable.
Mode changes require careful migration
FortiOS can carry VIP objects between central and non-central NAT modes, but documentation notes that a VIP assigned to a firewall policy in non-central mode must be unassigned before switching to central mode.
Source NAT also changes from per-policy configuration to central table entries.
Export the current configuration, map every source/destination translation, and validate representative sessions before and after the mode switch.
Policy-based NGFW mode changes the assumption
Current FortiOS notes that central NAT, specifically central SNAT, is implicitly enabled in policy-based NGFW mode.
This is an important architectural distinction because engineers moving between profile-based and policy-based modes can have different expectations about where translation is configured.
Operational documentation should state the NGFW policy mode and central-NAT state for every managed FortiGate estate.
IP pools should map clearly to business purpose
Central SNAT is useful when several internal networks need different public pools, tenant egress identities, partner source addresses, or application-specific translation.
Name pools and rules after the business or routing purpose rather than generic labels such as pool1.
Clear naming makes it easier to investigate when a destination allow list sees an unexpected source address.
Routing must still select the intended egress interface
NAT does not replace routing. The firewall needs a valid route toward the destination, and central-SNAT rules can match outgoing interface.
An SD-WAN or routing change can therefore alter which central NAT rule matches if the session leaves through another interface.
The existing FortiGate routing and SD-WAN article is relevant because route selection and translation policy should be reviewed together.
HA and NAT state need failover testing
FortiGate HA synchronizes many session and NAT states depending on configuration and session type.
A central-NAT migration or new IP pool should be tested during HA failover so translated sessions and upstream return paths behave as expected.
FortiGate HA Failover covers the session-synchronization side of that design.
Logs should preserve original and translated context
Traffic investigation needs the original source/destination, translated values, matching firewall policy, and session path.
Forward those fields into FortiAnalyzer or SIEM systems where incident responders can search them consistently.
A translation model that cannot be reconstructed from logs creates unnecessary ambiguity during incident response.
Central NAT is successful when translation becomes easier to govern without becoming harder to explain
The design is valuable when large estates gain one dedicated ordered translation policy, clear IP-pool ownership, controlled migration, and straightforward troubleshooting.
Every session should still be explainable as route selection + security policy + central NAT rule + resulting session state.
Central NAT is particularly useful in large estates where security-policy ownership and IP-address-management ownership are separate. The firewall team can maintain security intent while a network or platform team owns egress pools, partner-specific translation, or public service mappings. That separation should be mirrored in change approval so one group does not accidentally invalidate the assumptions of the other.
Rule comments and naming should capture the business reason for translation. A central-SNAT entry such as ERP-to-PartnerA-egress is easier to troubleshoot than a numeric label when a partner reports traffic from an unexpected public address. Include source/destination purpose and owning application where the platform allows it.
Overlapping networks are another central-NAT use case, especially during mergers or multi-tenant environments. Translation can create unique address space at the boundary, but design must account for return routing and logging. Teams should preserve both pre- and post-NAT identities so incidents can still be traced to the original internal workload.
VIP lifecycle should be integrated with service lifecycle. When an application is retired, remove the central-DNAT VIP, related policy, DNS records, and any upstream allow lists rather than leaving a public translation object active indefinitely. Stale VIPs increase attack surface and make address reuse risky.
Port translation deserves explicit documentation. Central SNAT/DNAT can alter ports as well as addresses, which can confuse packet captures and upstream monitoring when teams compare one side of the firewall with the other. Record the expected original and translated five-tuple for critical services.
Automation should validate rule shadowing. Infrastructure-as-code or FortiManager-driven workflows can check whether a new broad central-SNAT entry will match traffic that previously hit a lower rule. Ordered translation policy benefits from the same predeployment linting used for security rules.
Debugging should use session and packet-flow evidence rather than GUI inspection alone. FortiGate diagnostics can show route lookup, policy match, NAT decision, and session table state. This is especially important when SD-WAN, policy routes, VIPs, and central NAT interact and visual configuration review becomes ambiguous.
Central NAT should be evaluated during disaster recovery. Secondary sites or HA members need access to the same public addresses, upstream routing, and return paths. If public IP pools exist only in one provider or circuit, firewall failover can succeed while translated application traffic still fails externally.
Central-NAT environments should standardize packet-flow troubleshooting. A useful runbook checks route/SD-WAN decision, firewall-policy match, central SNAT or VIP/DNAT match, session-table translation, and return traffic. Keeping the sequence consistent reduces the temptation to change multiple rules at once when one translated session fails.
Address-pool exhaustion should be monitored where dynamic pools or port translation serve high-volume users. A NAT rule can be configured correctly while new sessions fail because available addresses or ports are exhausted. Session counts, pool utilization, and traffic growth should therefore be part of capacity planning for shared egress pools.
Partner integrations deserve stable egress policy. External parties often allow-list one public source range; an SD-WAN path or ISP change can select another pool if central SNAT is tied to egress interface. Document failover behavior and provision allow lists before the alternate path becomes active during an incident.
Central NAT should be reflected in FortiManager governance. If FortiManager is the source of truth, translation objects and ordered rules should be changed centrally and installed with the related firewall-policy change when both are part of one release. Editing the FortiGate locally can create drift that is especially difficult to diagnose later.
Documentation should capture whether the organization uses central NAT consistently or only in selected FortiGate estates. Engineers moving between firewalls can make dangerous assumptions if one device uses policy NAT and another uses central SNAT. Put the mode in runbooks, FortiManager metadata, and troubleshooting checklists.
Testing should include both directions of every critical translated service. For inbound VIP/DNAT, verify external-to-internal reachability and internal return traffic. For outbound SNAT, verify the destination sees the expected translated source and that return traffic maps to the correct session. Translation success is an end-to-end property.
A mature central-NAT design makes translation policy reusable and centrally governed while keeping session behavior transparent enough that network, security, and application teams can all reconstruct one flow without guessing which layer changed the address.
