FortiGate NSE4: Central NAT vs Policy NAT – Lab Scenario Showdown

Network Address Translation (NAT) on FortiGate firewalls can be configured in two fundamentally different ways: Central NAT and Policy NAT. While both achieve address translation, they operate at different stages of the packet processing pipeline and serve different use cases. Understanding when and how to use each method is essential for NSE4 certification and production deployments.

What is Central NAT?

Central NAT is applied before the security policy evaluation in the FortiGate packet processing flow. It translates source or destination addresses globally, independent of which policy the traffic matches. Central NAT rules are processed sequentially and apply to all traffic that meets the match criteria, regardless of the security policy outcome.

Central NAT is configured under Firewall -> Address Translation -> Central NAT in the GUI, or via the CLI using the 'config firewall central-nat-service' command. This approach is ideal when you need consistent NAT behavior across multiple policies or when NAT decisions should not depend on policy-specific logic.

config firewall central-nat-service
  set status enable
end

config firewall ippool
  edit "pool-1"
    set startip 192.168.1.100
    set endip 192.168.1.120
  next
end

config firewall central-nat-map
  edit 1
    set srcintf "port1"
    set dstintf "port2"
    set srcaddr "all"
    set dstaddr "all"
    set service "all"
    set action source-nat
    set ippool "pool-1"
  next
end

What is Policy NAT?

Policy NAT is applied within the security policy itself and is evaluated only if the traffic matches that specific policy. The NAT action is tied directly to the policy, meaning different policies can apply different NAT rules to the same traffic based on other match criteria like application, user, or destination.

Policy NAT is configured directly in the security policy settings. When you enable source NAT or destination NAT on a policy and assign an IP pool, that NAT rule applies only to traffic that matches that policy. This provides granular, policy-specific control over address translation.

config firewall policy
  edit 1
    set name "Internal-to-External-NAT"
    set srcintf "internal"
    set dstintf "external"
    set srcaddr "LAN-Subnet"
    set dstaddr "all"
    set action accept
    set service "all"
    set nat enable
    set ippool "pool-1"
  next
end

Key Differences and When to Use Each

• →Processing Order: Central NAT is applied before policy lookup; Policy NAT is applied after policy match.
• →Scope: Central NAT applies globally to matching traffic; Policy NAT applies only within the matched policy.
• →Flexibility: Policy NAT allows different NAT rules for different policies; Central NAT is uniform across all traffic.
• →Performance: Central NAT can be more efficient for high-volume scenarios with uniform NAT requirements.
• →Use Central NAT for: Site-to-site VPN scenarios, consistent outbound masquerading, or when NAT must not depend on policy.
• →Use Policy NAT for: Fine-grained control, different NAT pools per destination, or application-aware NAT decisions.

Lab Scenario: Choosing the Right Approach

Consider a company with two Internet uplinks. Traffic destined for ISP-A should use NAT pool 10.0.0.100-10.0.0.110, while traffic for ISP-B should use pool 10.0.0.200-10.0.0.210. Policy NAT is the correct choice here because each policy (one per ISP) can specify its own IP pool. Central NAT would require more complex route-based logic and would not provide the policy-specific granularity needed.

Conversely, if your organization needs all internal users to appear as a single public address regardless of destination, Central NAT with a single IP pool is simpler and more efficient. It eliminates the need to configure NAT in every outbound policy.

Mastering these two NAT methods is critical for NSE4 exam success and for designing robust FortiGate deployments. The choice between them directly impacts your firewall's performance, maintainability, and security posture.