ASA 8.4 Policy Nat

I came across a situation recently whilst in the middle of an ASA migration to a partner organisation whereby I needed to PAT connections to a particular set of destination addresses.

This is easily possible on the ASA by using 'Twice NAT'.

Twice NAT will make a NAT decision based on both the source and the destination. 

Regular Auto or Object Based NAT can only make a NAT decision based on the source or the destination.

Consider the following topology:

ASA 8.4 has no concept of nat-control so by default it will just route packets without any NAT rules being required.

I start by configuring two ACL's, one on the inside to allow any IP traffic outbound and one on the inside two allow ICMP traffic inbound:

With no specific NAT configuration, the packet is simply routed:

Ping from R1 Loopback1 to R2:

Ping from R1 Fa0/0 to R2

As we can see, the destination for the echo reply from R2 is the same address we sourced it from, i.e. NO NAT.


So let's say I now want to PAT everything from a specific set of source addresses to a particular set of destination addresses.

In my example, I want to translate any traffic sourced from R1's Loopback1 (10.1.1.1) that is destined to R2's Loopback1 (20.1.1.1) to a PAT address of (10.10.10.10)

First of all, I need to define my 'real' source addresses, i.e the source of the traffic I want to NAT:

Next, I define the address I would like to PAT to, I've decided to keep it simple and use an object (not object-group) that defines a single host address:

Now, I need to define the destination addresses that I would like to apply the NAT rules to, i.e. when connecting to these addresses, apply the NAT:

Finally, I tie it all together with a manual NAT statement:

The syntax of the NAT command might seem a little strange at first. What we're saying is that the source addresses are the 'real' ip's from the inside (R1's Lo1), we're then changing the source to the PAT address (10.10.10.10), but only when the destination matches the addresses in the 'DESTINATION_REAL' object-group (R2's Lo1).

The reason we specify 'DESTINATION_REAL' twice, is that if we wanted to, we could also change the destination address. In this example, I'm preserving the destination address, so it remains unchanged.

We can verify the changes:

As you can see, the ICMP's sourced from R1's Lo1 are translated to 10.10.10.10.

Pings from any other source address are routed normally with no translation occurring: