Configuring & Verifying FTD NAT

"The What?" - In this post I will cover configuring NAT on Cisco FTD. Then I will walkthrough how to verify deployment with successful translations. The topology used to demo is below:

"The Why?" - NAT provides many advantages. One major advantage being the fact that we can hide an entire internal network behind one address. NAT also enables private networks to connect with the internet even if they use private IP addresses. NAT is a solution that aides in preventing the depletion of IPv4 addresses. Lastly, NAT is often a desire to increase security.


"The How?" - Now I will dive into the meat & potatoes. A quick note, ACP (access-control policy) rules must be created to allow the desired traffic to flow through FTD. All rules are pre-configured and omitted.


To start, the following is how to navigate within FMC to begin setting up a NAT FTD policy:


Devices -> NAT -> Click the Edit for FTD -> Add Threat Defense NAT Policy -> <NAME> -> Select FTD and Save.

Note: Only adding my ftd3 device as the ftd4 is a transparent instance.


Once you configure a new Threat Defense NAT policy you will be taken to the following to actually begin staging your NAT rules (at first you will have a clean slate):

Now that we are ready to begin staging the NAT rules I intend on walking through several examples using the topology shared above.


Before we start here is a refresher on NAT in general:

The differences between Auto NAT & Manual NAT:

  • Auto NAT makes decisions only on the source

  • Auto NAT can only translate the source

  • Manual NAT can make a decision on both source/destination

  • Manual NAT can translate the source/destination, and even both at the same time

The main types of translations:

  • Static NAT = translation of just an IP Address, where the post-translation address is explicitly defined.

  • Static PAT = translation of an IP address & port, where the post-translation attributes are explicitly defined.

  • Dynamic NAT = translation of just an IP address, where the post-translation is selected via device.

  • Dynamic PAT = translation of both IP & port, where the post-translation attributes are selected via the device.

The last item to cover is NAT precedence. Every Manual NAT statement takes precedence over every Auto NAT statement. However, if you wish to de-prioritize a Manual NAT statement so that it occurs after Auto NAT you can configure it to be below all Auto NAT statements by deploying it into the third section. Now, with FTD NAT there are three sections that all NAT statements fall into which declares order of operation. These sections are:

  1. Section 1: Manual NAT or Twice NAT

  2. Section 2: Auto NAT or Object NAT

  3. Section 3: Manual NAT when specifying 'after-auto' in NAT rule

Ok so now that we recapped/covered the general understanding of NAT it is time to go over the examples:


Dynamic NAT example:

For the FTD dynamic auto NAT example I will dynamically translate the inside interface network (10.10.11.0/24) to a range that FTD will use to dynamically translate the source address to (pool = 10.100.100.1-10.100.100.10).


FMC FTD NAT policy configuration:

First select add new rule. Once done, you determine the type along with other information such as interfaces & translation pool etc.:

Configuration in FMC continued:

Note once done you must deploy policy to FTD instance.


FTD CLI Config after policy deployment:

FTD CLI NAT translation verification (ping traffic to initiate testing):


Dynamic PAT:

For an FTD dynamic PAT example I will configure a NAT rule that will allow the dmz_1 interface network (10.10.10.0/24) to use the outside interface IP. Emulating a many-to-one NAT rule.

FMC configuration snippet:


This example gets configured as an auto-nat rule since we are only performing the NAT translations based on the source address.


Static NAT:

For an FTD static NAT translation I will translate the dmz2_loopback when attempting to reach the inside interface network. This time I will create the rule as manual NAT.

FMC snippet:


Final NAT Policy snippet from the examples above:

Final NAT verification from FTD CLI:

To view translation table: >show xlate

Lastly, a brief reminder/overview on the following NAT types that were not shown:

  • Policy NAT: Policy NAT allows us to translate traffic based on destination. Very important note: Policy NAT is configured with manual NAT since it includes src/dst. Policy NAT cannot be configured using Auto NAT syntax.

  • Twice NAT: Twice NAT is a unique NAT translation where we can translate both the source & destination address, AKA NAT two times.

  • Static PAT: Static PAT are translations where both the IP & ports are being modified, and the mappings are explicitly defined.

That wraps up this post on FTD NAT. Check out more via the <ftd> tag. Cheers!

0 comments

Recent Posts

See All

Email Security - Breaking Down DKIM & DMARC

I recently started pursuing email security studies. Other posts have mentioned this, and a recent post shared a deeper look at SPF. In this blog I want to cover DKIM & DMARC. Starting with DKIM, it

Email Security - Breaking Down SPF

In the post I want to breakdown & cover SPF in more detail. Especially as I continue to embark on the email security journey/track. before beginning, here is another brief overview of what SPF entai

Understanding FTD Multi-Instance Capability Mode

In this post I want to cover running the multi-instance capability with Firepower Threat Detection (FTD). This capability lets you run containers that use a batch of resources of the security module/