NAT control is one of those features people found (find) confusing on the Cisco ASA. Even though this feature has now been deprecated (consider word choice) in newer ASA versions (8.3+), there are many organizations still using pre-8.3 ASA versions and I hope this article will be of help to anyone who has to manage such devices.

CCNA Training – Resources (Intense)

Before we go into any configuration, let’s highlight a few details about NAT control:

  • It requires that traffic going from a higher-level security interface to a lower-level security interface match a NAT rule.
  • Even if NAT control is enabled, traffic flowing between the same security level interfaces do not need to match a NAT rule. However, if you configure a dynamic PAT/NAT on a same security level interface, then all traffic from that interface to other same security level interfaces must match a NAT rule.
  • NAT control does not affect static NAT.
  • If you configure outside NAT/PAT, then all traffic from the outside to the inside must match a NAT rule.

Let’s now take a deeper look into NAT control by setting up a lab as shown below:

I am using ASA version 8.0(2) where NAT control is disabled by default as shown below:

The configuration on the ASA is shown below. Notice that this configuration enables NAT control, permits communication between interfaces of the same security level, and also enables ICMP inspection under the default MPF configuration.

interface Ethernet0/0
 nameif outside
 security-level 0
 ip address 192.0.2.1 255.255.255.0 
!
interface Ethernet0/1
 nameif inside1
 security-level 100
 ip address 10.1.1.1 255.255.255.0 
!
interface Ethernet0/2
 nameif inside2
 security-level 100
 ip address 10.2.2.1 255.255.255.0 
!
same-security-traffic permit inter-interface
nat-control
!
policy-map global_policy
 class inspection_default
  inspect icmp

The routers all have an IP address ending with .100 and the ASA configured as their default gateway.

Scenario 1: Traffic from Inside1 to Outside

Because the inside1 interface is on a higher security level (100) than the outside interface (0), then traffic from inside1 to the outside must match a NAT rule. If that traffic does not match any NAT rule, we will get an error in the ASA logs as follows: “No translation group found …”

! ***Ping from INSIDE1 router to OUTSIDE router ***
INSIDE1#ping 192.0.2.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.0.2.100, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
!
! ***Logs on ASA ***
%ASA-7-609001: Built local-host inside1:10.1.1.100
%ASA-7-609001: Built local-host outside:192.0.2.100
%ASA-3-305005: No translation group found for icmp src inside1:10.1.1.100 dst outside:192.0.2.100 (type 8, code 0)

Let’s add a dynamic PAT rule as follows:

nat (inside1) 1 10.1.1.0 255.255.255.0
global (outside) 1 interface

Now we will ping again:

INSIDE1#ping 192.0.2.100 repeat 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 192.0.2.100, timeout is 2 seconds:
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 8/10/12 ms
INSIDE1#

Hint: If you didn’t enable ICMP inspection or permit ICMP echo reply in an ACL, then the ping would not have been successful. However, something like Telnet will be successful because TCP stateful inspection is enabled by default.

Scenario 2: Traffic from Inside1 to Inside2 (with dynamic NAT/PAT)

Before we perform this test, I will remove the NAT statement we configured in the previous scenario (I will explain why I’m doing this later):

no nat (inside1) 1 10.1.1.0 255.255.255.0

When discussing the details of NAT control, we said that even if NAT control is enabled, traffic between the same security interfaces do not have to match a NAT rule. Since inside1 and inside2 have the same security level of 100, then we do not need any NAT rules for communication between these two interfaces.

To test this, I will ping from INSIDE1 router to INSIDE2 router:

INSIDE1#ping 10.2.2.100 re 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 10.2.2.100, timeout is 2 seconds:
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 12/16/20 ms
INSIDE1#

As you can see, the ping was successful. There was an exception to the fact that same security interfaces do not need NAT to communicate – if dynamic NAT/PAT is configured, then traffic must match a NAT rule. Therefore if we have the dynamic PAT for inside1 to outside flow, then inside1 to inside2 will fail without a NAT rule.

! ***Add NAT rule back on ASA ***
nat (inside1) 1 10.1.1.0 255.255.255.0
!
! ***Ping from INSIDE1 router to INSIDE2 router
INSIDE1#ping 10.2.2.100 re 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 10.2.2.100, timeout is 2 seconds:
..
Success rate is 0 percent (0/2)

If you use the packet-tracer command on the ASA, it will tell you the reason this traffic was denied as shown below:

There are two ways to resolve this issue. The first is to configure NAT exemption for traffic from inside1 to inside2 as follows:

access-list NAT_EXEMPT extended permit ip 10.1.1.0 255.255.255.0 10.2.2.0 255.255.255.0
nat (inside1) 0 access-list NAT_EXEMPT

The other way is to configure static identity NAT for the inside1 subnet on the inside2 interface:

static (inside1,inside2) 10.1.1.0 10.1.1.0 netmask 255.255.255.0

Scenario 3: Traffic from Inside1 to Inside2 (with static NAT)

In the preceding scenario, we saw that once a same security interface is configured with dynamic NAT/PAT, traffic from that interface to other same security interfaces must match a NAT rule. However, this does not apply when static NAT is configured.

To test this, I will remove the dynamic PAT configuration for inside1 to outside and replace it with a static NAT configuration.

no nat (inside1) 1 10.1.1.0 255.255.255.0
static (inside1,outside) 192.0.2.10 10.1.1.100

Note: Also remove the fixes from the previous scenario i.e. NAT exemption or static identity NAT.

With this configuration, INSIDE1 router can ping both OUTSIDE router and INSIDE2 router meaning that it did not need to match any NAT rule going to INSIDE2 router.

INSIDE1#ping 192.0.2.100 repeat 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 192.0.2.100, timeout is 2 seconds:
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 4/6/8 ms
INSIDE1#ping 10.2.2.100 repeat 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 10.2.2.100, timeout is 2 seconds:
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 20/64/108 ms
INSIDE1#

Scenario 4: Traffic from Outside to Inside1

Let us assume the outside network (or any lower security interface) should be allowed to ping the inside1 host (10.1.1.100) on 192.0.2.10 (static NAT). We can permit this in an ACL:

static (inside1,outside) 192.0.2.10 10.1.1.100
access-list OUT_IN permit icmp any host 192.0.2.10
access-group OUT_IN in interface outside

With this configuration, I will try to ping the INSIDE1 router from the OUTSIDE router and we will see that it goes through:

OUTSIDE#ping 192.0.2.10 re 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 192.0.2.10, timeout is 2 seconds:
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 72/154/236 ms
OUTSIDE#

Let us now configure outside NAT such that the address of the OUTSIDE router is also translated to 10.1.1.10.

nat (outside) 2 192.0.2.100 255.255.255.255 outside
global (inside) 2 10.1.1.10

We can test the ping from the OUTSIDE router to INSIDE1 router:

OUTSIDE#ping 192.0.2.10 re 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 192.0.2.10, timeout is 2 seconds:
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 8/18/28 ms
OUTSIDE#
!
! ***ICMP debug on INSIDE1 router shows that the translation is working ***
INSIDE1#
*Mar  1 00:13:17.703: ICMP: echo reply sent, src 10.1.1.100, dst 10.1.1.10
*Mar  1 00:13:17.751: ICMP: echo reply sent, src 10.1.1.100, dst 10.1.1.10

So that ping is successful. However, the issue is that since NAT control is enabled, all traffic from the outside to the Inside1 (or Inside2) will need to match a NAT rule. This means that a host 192.0.2.101 for example, will not be able to ping the INSIDE1 router. We can use packet-tracer to confirm this:

packet-tracer in outside icmp 192.0.2.101 8 0 192.0.2.10
...output omitted
Phase: 7
Type: NAT
Subtype:
Result: DROP
Config:
nat (outside) 0 0.0.0.0 0.0.0.0 outside
nat-control
  match ip outside any inside1 any
    no translation group, implicit deny
    policy_hits = 1
Additional Information:

Summary

This brings us to the end of this article where we have discussed NAT control in ASA version 8.3 and before. We have seen that when NAT control is enabled, traffic from higher security level interfaces must match a NAT rule when going to lower security level interfaces. Also, traffic between same security level interfaces do not need to match NAT rules except if dynamic NAT/PAT is configured on a same security level interface. Finally, if outside NAT/PAT is configured, then all traffic from the outside to the inside must match a NAT rule.

I hope you have found this article informative.

References and Further reading