Can I switch to central NAT on a running FortiGate?

Only after removing every VIP and IP pool reference from the firewall policies; FortiOS refuses the change while policies still use them. Plan it like a migration: list the current translations, write the equivalent central rules, then switch in a maintenance window.

Which mode should I choose?

Policy NAT suits most networks and is what most FortiGates run. Central NAT helps where many policies share the same translations, or where a separate team owns NAT, because translations are defined once instead of on every policy.

FortiGate Central NAT: Central SNAT Map and DNAT | FortiGate Course

Central NAT

Moving NAT out of firewall policies into a central SNAT table and automatic DNAT, and when that design is worth it.

Advanced · 9 min read

What you will learn

After this lesson, you can explain how central NAT differs from policy NAT, write central SNAT rules, and write a policy for a published server when DNAT is central.

Central SNAT map
DNAT without VIP in policy
Policy vs central NAT

Central NAT is an optional FortiGate mode that moves address translation out of firewall policies. Source NAT is defined in a separate central SNAT table, checked top-down, and VIPs (destination NAT) apply to matching traffic automatically. Firewall policies then only decide whether traffic is allowed, and for published servers they refer to the real internal address.

In simple terms: Instead of ticking NAT on every rule, all translations are kept in one list of their own. The rules only say yes or no.

A real-life situation

A company has 300 policies on its FortiGate, and translations are scattered across them: some use the interface address, some an IP pool, a few have NAT off by mistake. An audit asks which public address each internal network leaves from. In central NAT mode that answer is one short table.

Policy NAT versus central NAT

	Policy NAT (default)	Central NAT
Source NAT	NAT and IP pool set on each policy	Central SNAT table, top-down, separate from policies
Destination NAT	VIP used as the policy's destination	VIPs apply automatically; policy uses the real server address
Policies	Decide access and translation	Decide access only

Enable it and write SNAT rules

config system settings
    set central-nat enable
end
config firewall central-snat-map
    edit 1
        set srcintf "port2"
        set dstintf "port1"
        set orig-addr "LAN-subnet"
        set dst-addr "Payment-Provider"
        set nat-ippool "Payments-Pool"
    next
    edit 2
        set srcintf "port2"
        set dstintf "port1"
        set orig-addr "LAN-subnet"
        set dst-addr "all"
    next
end

Rule 1 translates payment traffic to the pool; rule 2 translates everything else from the LAN to port1's address (no pool means the outgoing interface address). Like policies, the first matching rule wins, so specific rules go first. Traffic that matches no SNAT rule leaves untranslated.

Published servers in central mode

The VIP VIP-WEB1-HTTPS stays as it is, but the policy no longer names it. Because destination NAT is applied automatically before the policy check, the policy matches the real address:

config firewall policy
    edit 6
        set name "Internet-to-WEB1"
        set srcintf "port1"
        set dstintf "port3"
        set srcaddr "all"
        set dstaddr "WEB1"
        set action accept
        set schedule "always"
        set service "HTTPS"
    next
end

dstaddr is the address object WEB1 (10.0.2.10), not the VIP. In central mode the policy has no NAT settings at all.

Why it works this way

Separating translation from access control lets each be read and changed on its own. The cost is that one session's behaviour is now spread over two tables, so troubleshooting means checking both: debug flow and the session list still show which policy allowed the session and which translation was applied.

Common mistakes

Enabling central NAT and forgetting the SNAT rules: LAN traffic leaves with private addresses.
Keeping the VIP as a policy destination in central mode, where policies must use the mapped address.
Ordering a general SNAT rule above a specific one.

Key takeaways

✅ Key takeaways

Central NAT moves SNAT into a separate top-down table; policies only allow or deny.
VIPs apply automatically, and policies refer to the real server address.
Policies must stop referencing VIPs and pools before central NAT can be enabled.
Policy NAT is the default and suits most networks.

Check yourself

Predict · scenario 1

In central NAT mode, what is the destination of the policy that allows Internet users to reach WEB1?

Predict · scenario 2

After enabling central NAT, LAN users can't browse. Policies allow the traffic. What is missing?

FAQ

Can I switch to central NAT on a running FortiGate?: Only after removing every VIP and IP pool reference from the firewall policies; FortiOS refuses the change while policies still use them. Plan it like a migration: list the current translations, write the equivalent central rules, then switch in a maintenance window.
Which mode should I choose?: Policy NAT suits most networks and is what most FortiGates run. Central NAT helps where many policies share the same translations, or where a separate team owns NAT, because translations are defined once instead of on every policy.