NAT on Cisco ASA (with GNS3 config)

Last Updated on May 3, 2018 by Valerio Plessi

In this article, we will be looking at Network Address Translation (NAT) on the Cisco ASA. I will assume the readers of this article know what NAT and the Cisco ASA are, so I will just give an overview. In the simplest form, the Adaptive Security Appliance (ASA) is Cisco’s implementation of a firewall and one of the fundamental functions of a firewall is to sit between internal and external nodes and provide security.

The current Cisco ASA models (now with FirePOWER services) include:

• Cisco ASA 5506-X
• Cisco ASA 5508-X
• Cisco ASA 5516-X
• Cisco ASA 5512-X
• Cisco ASA 5515-X
• Cisco ASA 5525-X
• Cisco ASA 5545-X
• Cisco ASA 5555-X
• Cisco ASA 5585-X

Although NAT can be defined more as a functional feature (translating a private IP address space to a smaller public IP address space), it can also be seen as a security feature (hiding real IP addresses).

Implementing NAT on Cisco ASA

The same way we have before Christ (BC) and anno Domini (AD) when talking about calendar dates, we have two main “eras” when talking about the Cisco ASA: pre-8.3 and 8.3+. These are not formal definitions but if you are familiar with the Cisco ASA, then you know things changed drastically between ASA version 8.2 and 8.3, one of them being NAT.

Side talk: don’t tell the customer but I once downgraded a customer’s firewall from ASA version 8.3 to 8.2 just so I didn’t have to worry about the NAT syntax change. Those were dark days…

Starting with ASA version 8.3, NAT can be implemented in two ways on the Cisco ASA:

• Network Object NAT
• Twice NAT

Apart from the way they are configured, the simplest way to understand the difference between these two forms of NAT implementation is that Twice NAT supports more complex NAT scenarios than Network Object NAT.

For example, if you want to translate an IP address to IP_A when going to Destination_A but the same IP address to IP_B when going to Destination_B, then you need Twice NAT. However, if you will be doing basic NAT operations, Network Object NAT is easier and recommended by Cisco.

We will now begin looking at different NAT types and see how they can be configured on the Cisco ASA. To keep things simple, we will begin with Network Object NAT and then consider Twice NAT in another article.

Lab Setup

I used GNS3 in this article and my lab setup is as shown below:

Note: All devices shown in the lab setup are simulated in GNS3 and the INSIDE-PC is a router because it just makes testing easier.

Dynamic NAT

Dynamic NAT allows translating a group of real addresses to a pool of mapped addresses. Usually, the mapped addresses are fewer (in number) than the real addresses; however, this is based on your traffic expectation.

Note: “Real” typically means the IP address(es) of a host/network before translation while “mapped” means the IP address(es) after translation (as seen on the destination network).

Let’s talk about a real world application of Dynamic NAT. Imagine you have a network with three sides as in our lab setup: inside, dmz and outside. Some users on the ‘inside’ will frequently need to access some servers in the ‘dmz’. However, for security reasons, we don’t want to reveal the real IP addresses of those ‘inside’ users to the DMZ. Dynamic NAT is suitable in this kind of scenario.

So how do we configure it? First, we need to create a network object for the real addresses (i.e. ‘inside’ network). Then, we will also create a network object for the mapped addresses (i.e. how the inside network should be seen on the ‘dmz’). Finally, we configure our NAT rule to tie both of them together.

object network REAL_INSIDE
 subnet 10.0.0.0 255.255.255.0
object network MAPPED_INSIDE
 range 172.16.1.150 172.16.1.160
!
object network REAL_INSIDE
 nat (inside,dmz) dynamic MAPPED_INSIDE

There are a couple of things to discuss in the configuration above. First, notice that Network Object NAT is configured under a network object (hence the name) – it is configured under the network object that defines the real addresses. Secondly, notice that we specified the real (‘inside’) and mapped (‘dmz’) interfaces. Finally, we specified the “dynamic” keyword to tell the ASA that this should be a dynamic translation versus a static translation. The difference between dynamic and static translation is that traffic initiation in one is unidirectional while the other can be bidirectional. We will talk more about this later.

Tip: Since you configure NAT under the ‘real’ network object, it is usually faster (less typing) to first create the ‘mapped’ network object and then create the ‘real’ network object and finally apply the NAT configuration.

Therefore, we can read the NAT configuration above as follows: when IP addresses configured under the REAL_INSIDE network object are going from the inside interface to the dmz interface, they should be dynamically translated to the MAPPED_INSIDE network object.

Let’s test our configuration. The best way to test our configuration will be to open a Telnet connection from INSIDE-PC to DMZ-RTR and use the who command to check our IP address:

As you can see, the real IP address of INSIDE-PC (10.0.0.100) was translated to one of the addresses in the pool of mapped addresses (172.16.1.153) when it initiated the Telnet connection. We can use the show xlate command on the ASA to see this translation:

Note that this translation will be active for as long as the connection is active; when the Telnet session is ended, the translation will be removed (after the timeout). This means that hosts on the destination network cannot initiate the connection to hosts on the real network. That is why we say traffic initiation in Dynamic NAT is unidirectional.

Note: It is possible for a host on the destination network to initiate a connection to a host on the real network as long as there is already a translation entry on the Cisco ASA. However, this is usually not practical because the host on the destination network will need to know the exact mapped IP address of the real host (which changes) and the connection will need to be allowed by an access rule.

Dynamic PAT

Dynamic PAT is similar to dynamic NAT except that it is used to translate multiple real addresses to just one mapped address (or multiple mapped addresses in a pool). It works by using ports for the translation – the real address and source port is translated to the mapped address and a unique port.

Dynamic PAT is ideal when you want to give an internal network access to the Internet. Because public IP addresses are scarce and expensive, you would normally translate the private IP addresses of all users on your internal network to a single public IP address that is routable on the Internet.

The configuration for Dynamic PAT is very similar to that of Dynamic NAT because you configure the ‘real’ network object, the ‘mapped’ network object and then the NAT configuration itself under the ‘real’ network object. However, with Dynamic PAT, you can also configure the mapped IP address inline the NAT configuration, that is, you don’t need a mapped network object.

Let’s take an example where IP addresses on the ‘inside’ network going to the ‘outside’ should be mapped to the ‘outside’ interface IP address of the ASA.

object network REAL_INSIDE_2
 subnet 10.0.0.0 255.255.255.0
 nat (inside,outside) dynamic interface

Note: You cannot configure multiple NAT statements under the same network object and that’s why I created another network object for the inside network.

To test, we can open a Telnet session from INSIDE-PC to OUTSIDE-RTR and check the IP address that shows up:

Dynamic NAT versus Dynamic PAT

So when will you use Dynamic NAT versus Dynamic PAT? When using Dynamic NAT, there’s the risk of running out of mapped IP addresses but Dynamic PAT allows you to maximize your mapped IP address especially when dealing with public IP addresses. However, not all types of traffic/applications support PAT. For example, Generic Routing Encapsulation (GRE) doesn’t use ports so PAT cannot work with GRE – no source port to translate. Here’s the final verdict: even when you use Dynamic NAT, you should configure Dynamic PAT as a fallback method.

Static NAT

Static NAT allows us to configure one-to-one mapping between a real IP address and a mapped IP address. One of the benefits of this is that traffic can be initiated in a bidirectional manner.

Note: There are other forms of Static NAT such as one-to-many, many-to-one, few-to-many and many-to-few.

For a real world application of Static NAT, imagine you have a web server in your DMZ that should be accessible from the Internet; you will configure Static NAT so that both the server and outside users can initiate traffic in either direction.

For our example, we will allow the DMZ-RTR to be accessed from the ‘outside’ via 192.0.2.5. Since the ‘dmz’ interface is on a higher security level than the ‘outside’, we will also need to allow this connection (from outside to dmz) in an access rule.

object network REAL-DMZ-SERVER
 host 172.16.1.5
 nat (dmz,outside) static 192.0.2.5
!
access-list OUT_IN extended permit ip any object REAL-DMZ-SERVER
access-group OUT_IN in interface outside

Note: In Cisco ASA version 8.3+, you always reference the untranslated/real IP address of a host in access rules irrespective of where the ACL is applied.

We can test our configuration in either direction: dmz to outside or outside to dmz:

Summary

Let’s stop here for now. In this article, you have been introduced to NAT on the Cisco ASA. We highlighted the two methods by which NAT can be implemented on the Cisco ASA – Network Object NAT and Twice NAT. We then went on to configure some NAT types using Network Object NAT.

In another article, we will consider more NAT types and also see how to configure Twice NAT. I hope you enjoyed this article and found it insightful.

Tip: you can also learn how to configure any Cisco ASA 5500 Firewall here, including VPNs configuration