Central NAT Table in FortiOS

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:

Figure. – Diagram of NAT Topology

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:

Figure. – Screenshot of default IP Pool definition in FortiOS
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:

Figure. – Screenshot of IPv4 Policy for 192.168.1.100
Figure. – Screenshot of IPv4 Policy for 192.168.1.200
Figure. – Screenshot of Consolidated IPv4 Policy

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:

Figure. – Screenshot of SSH Session to FortiOS with Central NAT enabled
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:

Figure. – Screenshot of navigation panel of FortiOS with Central NAT enabled

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:

Figure. – Screenshot of Central NAT table for host 192.168.1.100
Figure. – Screenshot of Central NAT table for host 192.168.1.200
Figure. – Screenshot of consolidated Central NAT table
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:

Figure. – Screenshot of IPv4 Policy with Central NAT enabled
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.

5 1 vote
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments