Modern Approach to Identity NAT (NAT 0) in Cisco ASA

In modern Cisco ASA versions (8.3 and later), **NAT 0** (also known as **Identity NAT**) has been replaced with a more intuitive approach using **object-based NAT** rules. The purpose of Identity NAT remains the same: to allow traffic to pass through the ASA without being translated, which is especially useful in scenarios like **VPN configurations**, where traffic between certain subnets needs to remain unmodified.

Here’s how Identity NAT (formerly NAT 0) is done today:

### 1. **Old Way (NAT 0)**:

In older ASA versions, you would configure NAT 0 (Identity NAT) to bypass NAT translation for specific traffic. For example, you might configure NAT 0 for traffic between two internal subnets or traffic going through a VPN tunnel:

nat (inside) 0 access-list NAT0_ACL

In this example:

- `nat (inside) 0` creates a NAT 0 rule for traffic on the inside interface.

- `access-list NAT0_ACL` defines which traffic should bypass NAT.

### 2. **New Way (Modern ASA Configurations)**:

In newer ASA versions (8.3 and later), the concept of NAT 0 has been replaced with **Identity NAT**, which is configured using **network objects** and **twice NAT** (manual NAT). Identity NAT is now just another form of NAT rule, where you explicitly define that the source and destination IPs should **remain unchanged**.

Here’s how you can configure Identity NAT today:

#### **Step 1: Define Network Objects**

You create network objects for the networks or hosts that should not be translated. For example, let’s say you want to ensure traffic between the `inside` network (`192.168.1.0/24`) and the `outside` network (`10.1.102.0/24`) remains untranslated (useful in a VPN scenario).

object network INSIDE_NET

 subnet 192.168.1.0 255.255.255.0

object network OUTSIDE_NET

 subnet 10.1.102.0 255.255.255.0

#### **Step 2: Configure Identity NAT**

You configure Identity NAT using the `nat` command with `source static` to ensure traffic between the inside and outside networks is not translated. This can be done using **twice NAT**, where both the source and destination networks remain unchanged:

nat (inside,outside) source static INSIDE_NET INSIDE_NET destination static OUTSIDE_NET OUTSIDE_NET

This command does the following:

- **(inside,outside)**: Indicates that the NAT rule applies to traffic going from the inside interface to the outside interface.

- **source static INSIDE_NET INSIDE_NET**: Specifies that traffic from the inside network (`192.168.1.0/24`) should not be translated (i.e., it stays static).

- **destination static OUTSIDE_NET OUTSIDE_NET**: Specifies that traffic destined for the outside network (`10.1.102.0/24`) also should not be translated.

#### **Step 3: Apply ACL for VPN Traffic (Optional)**

In VPN configurations, you may want to ensure that only traffic passing through the VPN tunnel is excluded from NAT. You can define an **Access Control List (ACL)** to specify the traffic that should bypass NAT for the VPN:

access-list VPN_ACL extended permit ip 192.168.1.0 255.255.255.0 10.1.102.0 255.255.255.0

Then, you apply this ACL to the **Crypto Map** used for the VPN, ensuring that the traffic between the two networks is passed through the VPN tunnel without being translated.

### Key Differences in the New Approach:

1. **Object-Based NAT**: NAT configurations are now based on network objects, which makes it more intuitive and easier to manage large-scale networks. Instead of manually defining rules for every subnet or host, you group them into network objects.

   

2. **Twice NAT**: Modern ASA devices allow for **Twice NAT (Manual NAT)**, which provides greater flexibility and control over both the source and destination address translations. This is particularly useful when configuring complex NAT rules for VPNs or multi-homed environments.

3. **No More NAT 0**: The old NAT 0 command is replaced by using network objects and twice NAT rules to specify that traffic should not be translated.

4. **Unified NAT Configuration**: Unlike the old NAT approach, where you had to configure NAT rules separately for different directions, modern NAT configuration allows you to manage source and destination NAT in a single statement, making it more organized and scalable.

### Example of Identity NAT for VPN:

If you are configuring Identity NAT for traffic going through a VPN tunnel between the inside network and the outside network, here’s a complete example:

#### Network Objects:

object network INSIDE_NET

 subnet 192.168.1.0 255.255.255.0

object network OUTSIDE_NET

 subnet 10.1.102.0 255.255.255.0

#### Identity NAT:

nat (inside,outside) source static INSIDE_NET INSIDE_NET destination static OUTSIDE_NET OUTSIDE_NET

#### ACL for VPN Traffic:

access-list VPN_ACL extended permit ip 192.168.1.0 255.255.255.0 10.1.102.0 255.255.255.0

#### Crypto Map (VPN):

You would then apply this ACL to the Crypto Map used for the VPN tunnel:

crypto map VPN_MAP 10 match address VPN_ACL

crypto map VPN_MAP 10 set peer <remote-peer-ip>

crypto map VPN_MAP 10 set transform-set <transform-set-name>

interface outside

 crypto map VPN_MAP

### Summary of the New Way:

- **NAT 0 is replaced** by **Identity NAT**, which is configured using object-based and twice NAT rules.

- **Object groups** are used to simplify the configuration and make it easier to manage large networks.

- **Twice NAT** allows you to configure more complex translation rules, controlling both source and destination translations.

- This method is **more flexible**, **scalable**, and better integrated with modern ASA features like VPNs and other security contexts.

In conclusion, while the concept of **Identity NAT** remains the same, the **new way** to configure it in modern ASA versions uses more powerful and scalable tools like **object-based NAT** and **twice NAT**, making it easier to configure and manage.