Hello!

In this series of posts, I’m going to discuss NAT on Firepower and the ASA in the way that I comprehend it. For this post I don’t plan on to getting too far into the configuration and verification aspects, we’ll dive into that later.

It’s not as complex as it looks.  Really.

In my opinion this is one of those topics where the difficulty level can be measured by the quality of your foundation knowledge. Put plainly – if you can clearly visualize what the traffic flow should look like, then it’s easy.   The actual configuration syntax is easy to learn and work with.  And although the configuration interface may look different, there is in actuality zero difference between FTD and ASA NAT.  So you only have to learn it once for both platforms, nice right?!?

Armed with these insights, let’s do a level set on traffic flows.  This baseline will give NAT syntax and semantics their context, so please at least skim it.  You can always come back to it as needed.

The 5 tuple flow (and stateful firewalls).

A unique IP traffic flow is defined by 5 fields.

• Source IP address
• Destination IP address
• Transport protocol (Ex: TCP/UDP)
• Source port
• Destination port

For the purpose of working with NAT, I find it helpful to visualize this in a left to right fashion like this:

[203.0.113.111| 10.10.10.10 | TCP | 50922 | 80]

In this example a device at 203.0.113.111 is communicating with a web server at 10.10.10.10

A conversation between two hosts can be seen as two unidirectional Flows were the IP addresses and Ports are a mirror image in the reverse direction.

Taking our above example, that is what the two flows in the conversation look like:

[203.0.113.111 | 10.10.10.10 | TCP | 50922 | 80]
[10.10.10.10 | 203.0.113.111 | TCP | 80 | 50922]

And that’s pretty much what it looks like in a packet capture:

firewall# capture example int inside
firewall# sh capture example

5 packets captured

1: 00:39:03.453925 203.0.113.111.50922 > 10.10.10.10.80: […] 1520352048:1520352048(0) win 4128 <mss 536>
2: 00:39:03.459921 10.10.10.10.80 > 203.0.113.111.50922: […]

 

A stateful firewall recognizes these mirror image flows and identifies them as related.  This simplifies usage – we only have to define our traffic rules in one direction, and the firewall can imply how the return traffic should be processed.

This logic also applies to NAT.  If you define the flow in one direction, the NAT engine in the firewall processes the mirror image packets to look for a match.

Note how the firewall sees the two flows as a single connection:

firewall# sh conn
1 in use, 1 most used

TCP outside 203.0.113.111:50922 inside 10.10.10.10:80, idle 0:00:07, bytes 0, flags UB

Nat rule types

FTD and the ASA have two types of NAT rules:  Auto and Manual.

Auto Nat

Auto NAT is the simplest and easiest form of NAT to configure.  I think of it as the microwave popcorn button of NAT.    We define a network object, then attach a NAT statement to the object that tells that firewall what translation we want to perform based on the source and destination interface.

Here is a basic example:

Object network Server-A
host 10.10.10.10
nat (inside,outside) static 203.0.113.10

This is how the fields relate to the flow:

Original packet:
[10.10.10.10 | 198.51.100.100 | TCP | 80 | 50922]
Translated packet:
[203.0.113.10 | 198.51.100.100 | TCP | 80 | 50922]

The individual components:.

Host 10.10.10.10 – The firewall will evaluate this against the first interface in the NAT statement.  With object NAT this is always going to be the source IP address

Nat (inside,outside) – The source ip address is coming from the inside interface of the router, and the destination ip address is on the outside interface of the router.  the destination interface is determined by the routing table.

Static – The source and destination address will be linked together in a fixed 1:1 relationship.  This is most commonly used for servers that require a fixed public (mapped) ip address.  Examples would be a web or email server.

203.0.113.10  – The mapped (public) ip address.  If source address, source interface, and destination interfaces all match, then the firewall will perform the translation.

Here’s what our NAT table looks like with the Auto Nat Rule Configured:

firewall# sh nat

Auto NAT Policies (Section 2)
1 (inside) to (outside) source static Server-A 203.0.113.10
translate_hits = 0, untranslate_hits = 0

Manual NAT

Manual NAT is useful for more advanced requirements, such as translating multiple fields in both directions, and conditional translation.

Happily, the way the NAT configuration syntax is structured makes it very easy to work with  once one can relate the fields in the flow to how that NAT statements are laid out.

In Manual Nat, the full five tuple flow can be matched and transformed. Be aware that unlike object Nat where the mapped address can be given directly, Manual Nat requires that all addresses/ranges/subnets in the statement be predefined as objects.

Manual NAT basic example:

Object network Server-A
host 10.10.10.10
!
Object network MAP-Server-A
host 203.0.113.10
!
nat (inside,outside) source static Server-A MAP-Server-A

As you can see, when you’re doing simple source translation Manual NAT requires more lines of configuration to accomplish the same result as auto nat.

Here’s what our NAT rule looks like for the above manual NAT example:

firewall# sh nat
Manual NAT Policies (Section 1)
1 (inside) to (outside) source static Server-A MAP-Server-A
translate_hits = 0, untranslate_hits = 0

Let’s look at common use for Manual NAT.  We’ll dive deeper in a subsequent post, This is just to give you a starting example.

Let’s say you’ve configured the Auto NAT translation shown earlier.  You are then asked to create a site to site VPN with a branch office.  In that case, when users from the branch office attempt to connect to Server-A, the auto NAT rule will kick in, translating the source address of the server on the return leg, and traffic will not return over the VPN tunnel.

10.10.11.11——————————————————————–>10.10.10.10
(Branch-PC)———-(Firewall)——–Internet——–(Firewall)——–(Server-A)
10.10.11.11<————————————————-*203.0.113.10—–10.10.10.10
*source IP in return traffic is translated, breaking the flow

So how do we fix this problem?  We use manual NAT to tell the firewall not to translate the address of Server-A when the destination is Branch-PC.  Like This:

Object network Srv-A
host 10.10.10.10
!
Object network Br-PC
host 10.10.11.11
!
exit
!
nat (inside,outside)  source static Srv-A Srv-A destination static Br-PC Br-PC

Here is the generalized form is what this statement is doing:
(incoming, exit) static source real mapped destination static real mapped

The important thing to grasp is that for both source and destination, we’re setting a condition.  Match this . If all conditions match, then change to this.

We’re telling the firewall, if you have this source and destination pair, Don’t change anything.  This overrides the Auto NAT and allows it and our VPN connection to co-exist.  This a use called Identity NAT.

 

Nat rule table structure

The Nat rule Table has Three sections.

1. Manual before auto

2. Auto

3. Manual After Auto

The user can set the order of the Manual NAT rules.  The Auto Nat rule order is set by the firewall automatically from most to least specific traffic match.  i.e. a host object would be ordered before a subnet object.

NAT table with Auto NAT rule, plus the identity nat override

firewall# sh nat
Manual NAT Policies (Section 1)
1 (inside) to (outside) source static Srv-A Srv-A destination static Br-PC Br-PC
translate_hits = 0, untranslate_hits = 0

Auto NAT Policies (Section 2)
1 (inside) to (outside) source static Server-A 203.0.113.10
translate_hits = 0, untranslate_hits = 0

Now a reason to order Manual NAT ahead of Auto NAT makes some sense right?

Wrap up

Well that’s quite a few words for an introduction, so let’s stop here.  In our next post we’ll go deeper into the terminology and usage examples .