In a previous post, I covered the default behavior for Network Address Translation (NAT) in FortiOS. However, understanding that there are, quite often, some difficulties in translating the NAT configuration from other platforms, I wanted to bring awareness to the Central NAT table feature in FortiOS.
Beyond having the inherent benefit of simplifying the configuration when migrating from other Next Generation Firewall platforms that use a separate NAT table, there are also some administrative overhead advantages that this method provides with complex NAT rules and access policies. For example, see the explanation of this in the next section.
Administrative Overhead with Default Method
Non-contiguous External Address Space
The default source NAT (IP Pool) method in FortiOS handles one-to-one mapping of contiguous address space. However, in the case where the address space is not contiguous, it can pose more administrative overhead. In the default NAT method, when using IP Pools with non-contiguous addresses, you have to define an individual access rule associated with each IP pool. See the following below as an example:

In the default behavior, the FortiOS administrator would need to create two IP Pools and two access rules to allow this to work. Here’s a screenshot of the GUI configuration and corresponding CLI associated with it:

config firewall ippool
edit "ip_pool-1.1.1.1"
set startip 1.1.1.1
set endip 1.1.1.1
next
edit "ip_pool-2.2.2.2"
set startip 2.2.2.2
set endip 2.2.2.2
next
end
Now that you have the two individual IP Pools defined, using the default NAT method, you would need to define the usage of these IP Pools within the IPv4 Policies. For example, let’s say you wanted to allow both of these hosts outside access to web servers on HTTP (TCP/80) and HTTPS (TCP/443) ports. Here’s the corresponding policies you would need to accomplish this:



While in small use cases, this may not add a lot of overhead in creating the policies, one can easily imagine the amount of policies required when attempting to build individual access rules for a multitude of hosts going to a multitude of destinations. Essentially, you would need to create a corresponding access rule for each individual host that references a different IP Pool.
Increasing Policy Creation Efficiency with Central NAT
The amount of administrative overhead associated with these types of policies can be greatly reduced with de-coupling the NAT functions with the firewall policy. That way, you can still define your NAT associations in a separate table but consolidate the firewall rules that define access for the related hosts. To accomplish this, the Central NAT feature in FortiOS can be enabled. To do this, see the CLI below:

config system settings
set central-nat enable
end
Please note: To enable this feature, you cannot have any reference of IP Pool objects within the existing IPv4 Policy. In other words, it’s best to enable this feature when you do not have any firewall rules that are referencing any kind of NAT configuration.
Once this feature has been added, you will note a few new options in your FortiOS Navigation panel:

To accomplish the same task referenced earlier, we need to create two separate IP Pools and reference the host to those IP pools in the “Central SNAT” table as shown below:



config firewall central-snat-map
edit 1
set orig-addr "h-192.168.1.100"
set srcintf "port2"
set dst-addr "all"
set dstintf "port1"
set nat-ippool "ip_pool-1.1.1.1"
set comments "host 100 outbound NAT rule"
next
edit 2
set orig-addr "h-192.168.1.200"
set srcintf "port2"
set dst-addr "all"
set dstintf "port1"
set nat-ippool "ip_pool-2.2.2.2"
set comments "Outbound NAT for host 200"
next
end
Now that the NAT has been defined in the Central NAT table, the remaining step is just to define the access policy in the normal IPv4 Policy as shown below:

config firewall policy
edit 1
set name "Outbound Access for hosts"
set uuid bc4023ee-b90b-51e9-5e7b-dc385974d18b
set srcintf "port2"
set dstintf "port1"
set srcaddr "h-192.168.1.100" "h-192.168.1.200"
set dstaddr "all"
set action accept
set schedule "always"
set service "HTTP" "HTTPS"
set fsso disable
next
end
A major difference with Central NAT functionality enabled is that the IPv4 Policy no longer has an option to define the NAT policy. Instead, there’s a message that informs the administrator that the NAT policy will be used from the matching Central SNAT policies. This greatly saves on administrative overhead especially when you have multiple access policies to provide controlled access to services from hosts that reference different IP Pools.
I hope this is an informative article that will greatly help in reducing the complexity of policy creation in FortiOS that requires complex NAT configurations. Please leave a comment below and let me know if this helps shorten the time required for managing your FortiGate.