In the previous article, we discussed three types of NAT implemented on the Cisco ASA: Dynamic NAT, Dynamic PAT and Static NAT. We also saw the different scenarios in which these NAT types can be used. In this article, we will see two more NAT implementations: identity NAT and static NAT with Port translation.

Identity NAT

The first one we will be considering is Identity NAT. This NAT type translates an address on the source network to the same address on the destination network. For example, in the diagram below, the IP address 10.1.1.1 on the inside is translated to the same IP address on the outside.

You may be wondering what use this will have so let me explain. Imagine you have a LAN including several network addresses like 10.1.1.0/24, 10.2.2.0/24 and so on. Now, all these networks connect to the Internet via the ASA using only one public IP address (i.e. Dynamic PAT). Imagine also that there needs to be a VPN connection between one of the internal networks, say 10.2.2.0/24, and another network external to the ASA.

In this scenario, identity NAT will help you create a mapping of that internal network (10.2.2.0/24) to itself to be used to bypass natting for the VPN. This is just one example of the use of identity NAT and we will see how this is done in an example.

Using the network diagram above, we will recreate what we just described. The LAN networks on the ‘HQ RTR’ will use the IP address of the ASA’s outside interface to connect to the Internet. This will be achieved using dynamic PAT as shown below. You should be familiar with the configuration for this from the previous article.

However, there should also be a VPN connection between the 10.2.2.0/24 network and the 10.3.3.0/24 network; this tunnel will be set up between the ASA and the ‘BRANCH RTR’. Even though the focus of this article is not on VPNs, I will show the configuration for the VPN on both the branch router and the ASA.

BRANCH RTR

ASA

The last line in the ASA is where the ‘magic’ actually happens and here we use the ‘Twice NAT’ implementation method to specify that when the LAN_10.2 (10.2.2.0/24) network is going to the EXT_10.3 (10.3.3.0/24), identity NAT should be applied.

Let’s test this configuration. First, we will telnet to the BRANCH RTR on its Internet interface (41.1.1.2) from the 10.2.2.0/24 network. This should match the Dynamic PAT that we configured and the connecting IP address should be seen as the ASA’s outside interface (41.1.1.1).

Now we can perform a second test. This time, we will initiate the telnet session to 10.3.3.0/24 from the 10.2.2.0/24 network. This should go through the VPN tunnel and the real IP address (identity NAT) should be seen as the initiating IP address.

Identity NAT does not have to be this complex (VPNs and stuff) but I have thought about the most reasonable situation for its use and that’s why we have done this. Now let’s move on.

Static NAT with Port Translation

An extension of the static NAT type is to specify a port number with the NAT mapping. Remember that the normal static NAT is usually a one-to-one bidirectional NAT implementation; however, with port translation, you have the added flexibility of mapping several IP addresses and port combinations to one (or several) public IP address and port combinations.

You will notice that with port translation, you can use the same mapped IP address for several real IP addresses. In that sense, we can say that static NAT with port translation can be seen as “dynamic PAT” without the dynamic nature because the ports are statically mapped and connection can be initiated from both directions.

Let’s look at the configuration. We will use both the Network Object configuration method and the Twice NAT method. Our network diagram remains the same as the one we used for Identity NAT. The first configuration will be to create a static NAT with port translation for the host with IP address 10.1.1.1. This NAT rule will use the ASA’s outside interface as the mapped address. You may remember that the ASA does not allow telnet connections on its lowest security interface. However, when there’s a NAT rule such as this one, the ASA simply redirects it. Let’s look closer.

I will now initiate a connection from the BRANCH RTR to 41.1.1.1 which is the IP address of the outside interface of the ASA.

This connection will fail – let’s see why (I hope you already figured it out).

Yes, we did not add an access rule to permit that connection. We cannot forget the default traffic flow on the ASA: higher security level to lower security level is permitted by default, but not vice versa. So let’s configure an ACL on the outside interface to allow that connection.

Let’s try that connection again.

Cool. Notice that even though the telnet was to the IP address of the ASA, because of the NAT rule, this was redirected to the host 10.1.1.1.

Let’s now configure the second rule using the Twice NAT configuration method. We will create a NAT rule that specifies that connections to 41.1.1.1 on port 222 should be redirected to 10.2.2.2 on port 22 (SSH).

Let’s test this NAT rule. We will tweak the SSH connection command a little by using the “-p” option which helps us specify what port to connect on.

And there we have it: the connection goes through to the correct host. In case you want to recreate some of these configurations, remember that your basic connectivity (routing, username/password combination, etc.) must be configured.

Summary

As you have seen from this article, the ASA supports some NAT types that can be used for more complex requirements. In the previous article, we configured simple forms of NAT like dynamic NAT, dynamic PAT and static NAT. In this article, we have taken it a step further by configuring Identity NAT and Static NAT with port translations. The truth is, I have had to configure some really “weird” NAT configurations based on client requirements, and knowing your way around NAT on the ASA is a useful skill.

One thing to keep in mind is the way NAT rules are ordered and implemented. You can find that in this table on the Cisco website.

I hope you have found this article helpful and I look forward to writing more insightful articles.