Hello!

Welcome to part 2 of this series of blog posts covering Network Address Translation on the ASA and Firepower threat Defense.  In this installment, we’re going to cover some terminology.

Notes on (confusing) terminology

Something that has always made NAT somewhat confusing to work with is overlapping terminology.  And it’s not just between vendors, or even vendor platforms, but also within the product documentation and the implementation of the same product.

Here’s the most relevant example.  The first screenshot is from the ASA 9.6 documentation. CLI book 2, NAT section.  The second screenshot is show output from an ASA that has the items referenced in the documentation snippet configured.

If you are brand new to the ASA, you’d never know from looking at these images that they are referencing the exact same thing.  When you’re trying to learn and discern what’s important, this terminology discrepancy presents an impediment.  This section is intended to help with that as best as I can.

Overall there are two categories where the terminology can be a bit confusing.  The first is items referred to with one term in the documentation, and a different one in the device .  We’ll call these synonymous terms:

The second is terms for what I would call use cases in the documentation, that don’t have an analog in the device configuration.  It’s just a term for specific use.  We’ll call these use case terms

When discussing configuring the technology where terms are synonymous, I’ll do my best to always use the term that’s referenced in the device configuration as it’s the most relevant.

When discussing use cases, I’ll point out where there’s a specific term defined for that use, but it’s not used anywhere in the device itself.

Synonymous terms

Auto NAT = Object NAT

They are the same thing,  the documentation calls it Object NAT, the command line interface calls it Auto NAT.  It’s called Object NAT in the documentation because the translation is always the property of an object.

!——-auto nat example—–!
object network foo
host 1.1.1.1
nat (i,o) static 2.2.2.2

Manual NAT = Twice NAT

They are exactly the same thing.  It’s called Twice NAT in the documentation to signify that both source and destination fields in the packet can be matched and altered.  NOTE: This can also be done with object NAT on a limited basis by using multiple statements, one in each direction.

!——-manual nat example—–!
object network foo
host 1.1.1.1
!
object network MAP-foo
host 2.2.2.2
!
object puppy
host 3.3.3.3
!
object MAP-puppy 1.1.1.2
!
nat (i,o) source static foo MAP-foo destination static puppy MAP-puppy

Use Case Terms

Identity NAT

Identity NAT is a use of Manual NAT.  The firewall is instructed  not to translate any of the fields in the flow.  This is used in situations where you would be performing NAT for most traffic flows, but you want to exempt speicifc destinations from translations.

The most common case for Identity NAT is VPN traffic..  As NAT is performed prior to encryption, most of the time you’ll want to make sure that the firewall doesn’t translate the source IP of the return packets, which prevent it from being sent over the tunnel as it would no longer match the crypto ACL.  Even if for the sake of argument the packet did get sent over the tunnel, because it’s source address has been altered, the receiving host would not recognize the packet as part of a flow and it would be dropped.

Here’s an illustrated example:

Policy NAT

Policy NAT is a use of manual NAT.  The term policy means setting the condition based on a specific destination.  Identity NAT does the same thing, but the difference is in the case of policy NAT a translation will be performed.

A common use for Policy NAT is Extranets and Software as a Service (SaaS) providers.  These types of connectivity typically call for the customer server to be seen as coming from a specific Mapped address.

For example, let’s say Server-web runs a web app that’s accessed from the Internet with Mapped address of 203.0.113.121.  A  SaaS provider needs to get information from this server, but the server-web must appear to be at the IP address 198.51.100.111, which has been designated by the SaaS provider.

Here’s a graphical representation:

 

Destination NAT

A strict definition of Destination NAT is Manual Nat where destination address and/or port number is being translated.  On the surface this implies the use of manual NAT, as it’s the only form of NAT that allows us to map the destination address or port to a different value.

Considered this for a moment:

Object network Server-A-In
host 10.11.11.11
nat (i,o) static 203.1.113.111
!
Object network Server-A-Out
host host 203.1.113.111
nat (o,i) 10.11.11.11

These two statements produce the exact same end result.  The distinction being with the second object, we’re making the public facing address the real address and the internal address the mapped address.   So the term destination NAT is really a matter of perspective.

Access Control Rule Processing and NAT

Access control rules in ASA NAT are always applied to the real address.  This is really very straightforward, but it can be a bit counter-intuitive at first.  Let’s illustrate with a simple example:

Let’s say we have a web server in a DMZ, and we want to allow access to it from the internet.

Object network server-web
host 172.16.1.11
nat (d,o) static 203.1.113.121
!
access-list outside-in permit tcp any host 172.16.1.11 eq www
access-group outside-in in interface outside
!

The intuitive thing would be to consider that an internet user would use the address 203.1.113.121 to access the web server, therefore that would be the destination IP you would use in the access control list.  so this is very confusing.  A good way to think of this is that we’re really applying the ACL to the object.  Since the object can only have one real address, but potentially many mapped addresses, it makes sense for the ACL logic work this way.

In fact, using objects and object groups in Access-control lists instead of bare ip addresses is quite handy.  If you get in the mindset of working with objects instead of addresses (which are the properties of an object), the operational logic of the ASA then becomes more intuitive.

Let’s re-write our ACL to use the object instead:

Object network server-web
host 172.16.1.11
nat (d,o) static 203.1.113.121
!
access-list outside-in permit tcp any host object server-web eq www
access-group outside-in in interface outside
!

Makes more sense now right?

 

Wrap up

My goodness, where does the time go.  In our next installment we’ll we’ll talk about static and dynamic NAT and PAT, services, objects and object groups.