ASA: NAT Theory and Configuration

 

With the introduction of Cisco ASA software version 8.3, significant changes were made to Network Address Translation (NAT) behavior, primarily to simplify configuration and eliminate confusion around IP references before and after NAT. These changes introduced two key concepts: Real IP and NAT Simplification.

 

Understanding NAT in ASA 8.3 and Beyond

In pre-8.3 versions, it was often unclear whether access control lists (ACLs) and configurations should reference the original IP (pre-NAT) or the translated IP (post-NAT). This led to frequent misconfigurations and troubleshooting headaches. To resolve this, ASA 8.3 introduced the concept of using Real IPs in security policies. This means that ACLs now refer to the original (pre-NAT) IP address of an internal device, rather than its translated address.

Additionally, NAT Simplification changed the internal packet inspection flow within the ASA. When a packet arrives, the ASA processes it as follows:

Hits interface → Routing → Un-NATs → Checks connection → ACL inspection

This sequence ensures that ACLs inspect the traffic based on the real IP (pre-NAT), making it essential for administrators to configure ACLs using those original addresses.

 

Real IP Configuration Example

To configure access to an internal server using real IPs, you must define an object with the server’s internal IP, configure a static NAT rule, and apply an ACL referencing the real IP. Here’s a sample configuration:

1. Define the object:

object network SRV
host 10.2.2.2

 

2. Configure static NAT:

nat (dmz,out) static 100.1.1.5

 

3. Permit external access using an ACL:

access-list OUTSIDE_IN permit tcp any host real-ip-addr-of-srv eq 80

In this example, the ACL uses the internal server’s real IP (10.2.2.2) rather than the translated NAT IP (100.1.1.5). This approach applies only to ASA versions 8.3 and later. In older versions, the NAT IP would be referenced instead.

 

SNAT, DNAT, and NAT Tables

To clarify terms:

• SNAT (Source NAT) modifies the source address of a packet, commonly used for outbound internet access.
• DNAT (Destination NAT) modifies the destination address, typically used for incoming traffic to internal services.

To verify and troubleshoot NAT entries, ASA provides two commands:

• show nat [detail] – Displays NAT rules based on the current configuration.
• show xlate – Displays active translation entries. For dynamic NAT, an xlate entry is created only after an internal host initiates a connection. In contrast, static NAT always maintains an xlate entry for the mapped IP.

 

Understanding NAT Types

Network Address Translation (NAT) enables the translation of private IP addresses into public IPs, allowing internal devices to communicate over the internet. This translation can be dynamic, commonly used for outbound client traffic accessing internet services, or static, which is typically used to allow internet-based users to reach internal servers.

 

Source NAT vs. Destination NAT

There are two fundamental NAT types:

• Source NAT is used when your internal (source) IP address is translated, regardless of the traffic direction. Think of it as “my IP is being translated.” This is the most common NAT type, used in approximately 99% of typical scenarios.
• Destination NAT occurs when the destination address (usually a public IP) is translated to an internal IP. This is commonly used to allow external users to access internal resources like web servers or mail servers. In this case, the address translation applies to “them,” or the remote side.

 

Simplified NAT Rule Structure in ASA

Starting with ASA version 8.3, Cisco introduced a simplified and unified NAT configuration model. Rather than applying NAT rules on a per-interface or security-level basis, all NAT rules are now part of a single global NAT table. This centralization allows for greater flexibility and decouples NAT from interface dependencies, ACLs, or security levels. You can even reference objects instead of manually typing IP addresses.

The global NAT table is divided into three distinct sections, each with its own function and priority:

 

Section 1: Manual NAT (also known as Twice NAT)

This section allows the administrator to manually define NAT rules with complete control. These rules can be inserted in any order, and Manual NAT takes precedence over Auto NAT (defined in section 2) unless explicitly configured otherwise. This section also supports policy-based NAT, which allows translation decisions based on both source and destination addresses.

 

Section 2: Auto NAT (also known as Object NAT)

Auto NAT is configured within the object definitions themselves. When you define an object and specify NAT within it, the ASA automatically places that rule into Section 2. However, Auto NAT does not support policy NAT—only one translation (source or destination) can be applied per object.

The ASA determines the order of Auto NAT rules based on several criteria, such as:

• Static rules over dynamic ones
• Longest prefix match
• Lowest numeric value in the first octet

This section is convenient but less flexible than Manual NAT.

 

Section 3: Manual NAT with After-Auto Keyword

This section uses the same configuration syntax as Section 1 but includes the after-auto keyword. This instructs the ASA to apply the rule after all Auto NAT rules have been evaluated, effectively giving it lower priority. This section is useful when you want a rule to apply only if none of the Auto NAT rules are matched.

By understanding these NAT types and the hierarchy of rule sections, you can more precisely control traffic flow through your ASA and troubleshoot NAT-related issues with confidence.

 

Understanding ASA NAT Order of Operations and Manual NAT Configuration

To effectively troubleshoot and design NAT policies on Cisco ASA, it’s essential to understand the NAT order of operations and how different types of NAT rules are prioritized and configured.

NAT Table Order of Operations

Cisco ASA processes NAT in a specific order, divided into three main sections:

1. Section 1 – Manual NAT (Pre-Auto NAT): These are explicitly defined NAT rules created in global configuration mode. They take priority and are evaluated before any Auto NAT rules.
2. Section 2 – Auto NAT (Object NAT): These are NAT rules configured inside the network object itself. This section is processed only if no match is found in Section 1.
3. Section 3 – Manual NAT (Post-Auto NAT): These are also globally defined NAT rules but are tagged with the after-auto keyword, meaning they are evaluated after Auto NAT.

Understanding this hierarchy allows engineers to control exceptions and precedence by placing rules in the appropriate section.

 

Manual NAT I

Manual NAT is defined in global configuration mode and gives granular control over NAT behavior. The syntax typically follows this format:

nat (inside,outside) [destination | source] [dynamic | static] pre_NAT_IP post_NAT_IP

For example:

nat (in,out) source static 10.2.2.2 100.2.2.55

This is functionally equivalent to:

object network SRV
host 10.2.2.5
nat (in,out) static 100.2.2.55

Manual NAT is especially powerful when specific, rule-by-rule translation is required, or when exceptions must override the object NAT defaults.

 

Object Networks in CLI

When defining NAT behavior through objects, administrators can specify:

• host – Used for a single IP address
• fqdn – Useful for NATing based on DNS-resolvable names
• range – Defines a pool of IPs for dynamic NAT or PAT
• subnet – Applies NAT to an entire network block
• description – Best practice for clarity and documentation

Example of configuring a dynamic NAT using a range and a subnet:

object network NAT
range 192.0.2.5 192.0.2.10

object network LAN
subnet 10.10.1.0 255.255.255.0

nat (inside,outside) dynamic NAT

 

Key Considerations for NAT Design

• Dynamic NAT and xlate Table Behavior: Dynamic NAT entries only persist in the xlate table while the session is active. Once the session is closed (via FIN or RESET), the mapping is removed.
• Dynamic Subnet Restrictions: A subnet cannot be a mapped source in dynamic NAT. If subnet NAT is needed, static NAT must be used instead.
• No Exclusion Lists in Auto NAT: Auto NAT does not support exclusion lists. If certain IPs need to bypass Auto NAT, use a manual NAT entry in Section 1 to override it.

 

NAT Exempt (Identity NAT)

NAT Exempt, or identity NAT, is used to prevent NAT from being applied in certain scenarios—such as traffic flowing through a VPN tunnel where translation to an external IP would break the session.

Example configuration:

object network LAN1
subnet 10.1.1.0

nat (inside,outside) dynamic interface

object network LAN2
subnet 10.2.2.0/24

nat (inside,outside) source static LAN1 LAN1 destination static LAN2 LAN2

This configuration allows traffic from LAN1 to LAN2 to bypass translation, ensuring direct communication between internal networks, often used in site-to-site VPN contexts.

By mastering the NAT order of operations and understanding the implications of using manual vs. object NAT, administrators can design resilient, predictable NAT policies and avoid common pitfalls like overlapping rules or unintended translations.

 

Object NAT Explained

Object NAT, also referred to as Auto NAT, is a simplified method of defining NAT rules within Cisco ASA by embedding the NAT configuration directly into a network object. This design allows you to specify a host address, subnet, or IP range and associate it with a NAT rule—all within a single, unified object. The benefit of this approach is streamlined configuration and easier management, particularly in dynamic environments where NAT rules are tightly coupled with specific resources.

Object NAT is ideal for simpler NAT scenarios where only one translation rule is needed per object. It’s important to note, however, that Object NAT does not support policy NAT, which requires evaluating both source and destination conditions.

Object NAT Syntax Options

Cisco ASA provides flexibility through the use of different object types for NAT configuration:

• object-group network name – This parameter allows you to define multiple networks, host IPs, or a combination of both within a single group. It’s particularly useful for scenarios where a set of addresses shares the same NAT behavior.
• object network name – This command defines a single network object, which may represent a host, subnet, or range. It’s the building block of Object NAT, and only one NAT rule can be associated with each individual object.

By leveraging Object NAT, administrators can consolidate NAT logic directly into their address object definitions, making configuration more modular and easier to maintain across large firewall deployments.

 

PAT (Port Address Translation)

Port Address Translation (PAT) enables multiple internal clients to share a single public IP address for outbound internet access. This is a standard solution for conserving public IPs while still allowing large-scale internal user connectivity. PAT works by translating not only the source IP but also modifying the source port number to ensure each session is uniquely identifiable. This port number is derived from the original packet and used as part of the translation mapping in the xlate table.

If two internal clients happen to use the same source port, the ASA firewall dynamically alters one of them to avoid conflicts. This dynamic handling of ports allows a single public IP to support thousands of simultaneous connections.

On average, one public IP address can support between 1,000 and 2,000 users, depending on the number of unique port mappings required per session. While there are over 60,000 TCP/UDP ports available, multiple ports may be consumed per user session, especially when users access complex sites or applications that open multiple parallel connections.

 

PAT Scalability and Considerations

PAT is ideal for environments with a large number of internal users, but it does come with some limitations:

• Portal Compatibility Issues: Some web portals (e.g., Yahoo.com) can trigger many simultaneous connections, each requiring a unique port. For example, a single web page load might initiate 50 separate connections, which can rapidly exhaust available port mappings.
• Overloaded Public IP Scenarios: High-volume services like Google or Facebook may flag traffic from a single IP as suspicious if too many users access the site concurrently. To prevent this from being interpreted as a denial-of-service (DoS) attack, Cisco introduced PAT Pools and Round-Robin Load Balancing starting in ASA IOS v9.2. These features allow the firewall to rotate through a set of public IPs, distributing the load across multiple addresses and avoiding IP exhaustion.

 

PAT Configuration Examples

To configure standard PAT where internal users share the IP of the ASA’s external interface:

object network INS-NET
subnet 10.0.0.0 255.0.0.0
nat (inside,outside) dynamic interface

This binds the inside network to the firewall’s outside interface, dynamically translating internal IPs and ports to the interface’s public IP and available ports.

Alternatively, for more scalable setups using a PAT Pool, you can define a dedicated public IP and assign internal subnets to use it via round-robin:

# Define the PAT pool IP
object network PAT-IP
host 192.1.20.11

# Assign inside subnet to use the PAT pool
object network INS-NET
subnet 10.0.0.0 255.0.0.0
nat (inside,outside) dynamic pat-pool PAT-IP

This configuration allows multiple inside hosts to be PAT’d through a designated public IP (192.1.20.11) instead of the firewall’s own interface address, which helps balance load and prevent port exhaustion under high user volume.

 

Object PAT and PAT Pool Configuration

Object PAT allows you to define dynamic port address translation (PAT) using network objects, making the configuration both modular and reusable. In a typical Object PAT setup, internal addresses are dynamically translated using the IP address of the firewall’s outside interface. For example:

object network LAN
subnet 10.1.100.0 255.255.255.0
nat (inside,outside) dynamic interface

In this configuration, traffic from the LAN subnet will be NAT’d using the interface’s IP with unique source ports assigned by the ASA to differentiate sessions.

For environments that require more scalability or load balancing, you can implement a PAT Pool. This involves specifying a pool of IP addresses and allowing internal users to be translated using any available IP in that pool:

object network PATPOOL
range 100.0.0.15 100.0.0.20

object network LAN
subnet 10.1.100.0 255.255.255.0
nat (inside,outside) dynamic pat-pool PATPOOL [block-allocation | extended | flat | interface | round-robin]

This configuration enables round-robin selection or specialized port handling based on the keywords appended.

 

Extended PAT Pool Options

When defining a PAT pool, several optional keywords can be used to fine-tune behavior:

• block-allocation – Allocates ports in blocks for a given session, improving performance for applications that use many concurrent connections.
• extended – Ensures uniqueness not only by source port but also by destination, allowing better NAT tracking across heavily multiplexed sessions.
• flat – Forces the translation of TCP and UDP ports into the full 1024–65535 range.
• interface – Uses the interface IP as a fallback or explicit mapped IP.
• round-robin – Distributes sessions evenly across the defined pool of PAT IPs, which is essential for scaling and avoiding port exhaustion.

An extended PAT configuration using a range of IPs with round-robin might look like this:

object network PATPOOL
range 100.1.1.15 100.1.1.20

object network LAN
subnet 10.1.100.0 255.255.255.0
nat (inside,outside) dynamic pat-pool PATPOOL round-robin

This setup ensures that internal sessions are distributed across multiple public IPs in a round-robin manner, reducing the chance of session limit issues from a single IP.

 

PAT Variants and One-to-Many Configurations

Cisco ASA also allows for more specific PAT mapping, such as many-to-one NAT using a single IP address that is not the physical interface IP:

object network LAN
subnet 10.1.1.0 255.255.255.0
nat (inside,outside) dynamic 100.1.1.5

Note: The IP address used here (100.1.1.5) must not be the physical IP of the interface.

Alternatively, you can fall back to interface PAT for simpler setups:

object network LAN
subnet 10.1.1.0 255.255.255.0
nat (inside,outside) dynamic interface

Each configuration option serves different needs, ranging from basic home office setups to complex, enterprise-grade, load-balanced NAT environments. By selecting the right form of PAT and tuning your configuration with extended keywords, you can build a resilient and scalable outbound access strategy using Cisco ASA.

 

Dynamic NAT

Dynamic NAT enables many-to-many IP translations, where internal users are dynamically assigned public IPs from a predefined pool. Unlike PAT (which uses port numbers for uniqueness), Dynamic NAT maintains a one-to-one IP mapping but assigns public IPs only as traffic flows are initiated. This is ideal when internal addresses need to appear as distinct public IPs, such as for licensing, geolocation, or filtering reasons.

A common example is mapping a private subnet like 10.1.1.0/24 to a public subnet such as 100.1.1.0/24. As users from the internal network access the internet, the firewall dynamically selects a public IP from the pool and creates a translation entry.

 

How Dynamic NAT Works

When a packet is sent from the inside network to the public internet:

1. The source IP is translated to a dynamically chosen public IP from the NAT pool.
2. The ASA firewall creates an entry in the xlate (translation) table only after the first packet of the session.
3. When the remote server responds, the firewall uses the xlate entry to reverse the translation, changing the destination IP back to the internal address.

Example Flow:

PC sends -> 10.1.1.5 | 199.1.1.1 | Data

Firewall translates -> 192.1.20.71 | 199.1.1.1 | Data
Xlate Table Entry: 10.1.1.5 -> 192.1.20.71

Remote Server replies -> 199.1.1.1 | 192.1.20.71 | Data

Firewall re-translates -> 199.1.1.1 | 10.1.1.5 | Data

Only once this communication is initiated will the dynamic mapping be visible in the show xlate output on the ASA.

 

Configuration Example

To implement dynamic NAT using a pool of public IPs, follow this two-step approach:

1. Define the public NAT pool:

object network MYPOOL
range 192.1.20.51 192.1.20.200

 

2. Assign a private subnet to use the pool:

object network LAN
subnet 10.1.1.0 255.255.255.0
nat (inside,outside) dynamic MYPOOL

You can also define both the public and private objects with more specific range references for complex setups:

# Define public NAT object
object network LAN-NAT
range 100.1.1.2 100.1.1.200

# Define internal subnet and bind NAT
object network LAN
subnet 10.1.1.0 255.255.255.0
nat (inside,outside) dynamic LAN-NAT

This ensures internal clients are dynamically assigned a public IP from 100.1.1.2 to 100.1.1.200 on a first-come-first-served basis. Once the pool is exhausted, no new translations will be created, making pool sizing important in large deployments.

Dynamic NAT is a great option for customers who need unique public identities without the port-sharing constraints of PAT. However, it does not scale as efficiently, so use cases should be carefully evaluated.

 

Static NAT

Static NAT creates a fixed, one-to-one mapping between an internal (private) IP address and an external (public) IP. This mapping is always active—an entry is permanently created in the ASA’s xlate table, unlike Dynamic NAT where entries are created only when traffic is initiated.

This NAT type is ideal for servers or devices on your internal network that must be consistently accessible from the public internet. For instance, if you have a web server in your DMZ that external clients need to reach via a public IP, you would use Static NAT. Since clients expect the same IP to be available at all times, the address translation must remain constant and predictable.

In a typical scenario, a server located behind the ASA might be mapped to a public IP like this:

object network WW1
host 192.168.1.11
nat (dmz,outside) static 192.1.20.21

This creates a permanent entry in the NAT table, ensuring that traffic destined for 192.1.20.21 is always translated to 192.168.1.11.

Key Characteristics and Differences

• The main difference between Static and Dynamic NAT is visibility in the xlate table. Static NAT entries are always present, whereas Dynamic NAT entries appear only after a session begins.
• You must still allow traffic using ACLs, especially when translating from a lower security level (like the outside) to a higher one (like the DMZ or inside).
• The translation is always 1:1—one inside IP maps to one outside IP.

 

Advanced Configuration and Options

You can further enhance Static NAT using additional flags. For example:

object network SRV
host 200.0.0.10
nat (dmz,outside) static 100.0.0.5 dns no-proxy-arp route-lookup

• dns – Rewrites DNS responses with the public NAT address.
• no-proxy-arp – Prevents the firewall from responding to ARP requests for the public IP on the egress interface.
• route-lookup – Forces the ASA to consult the routing table for this NAT rule.

These options are particularly helpful in complex networks with advanced DNS, security, or routing requirements.

 

ACL Considerations with Static NAT

For Static NAT configurations on ASA 8.3 and later, NAT occurs before ACL evaluation. That means your ACLs must reference the real (pre-NAT) IP address of the internal resource, not the public IP. If traffic is arriving from a lower-security interface like the internet, you’ll need to permit it explicitly.

Here’s an example ACL allowing access to various services on 192.168.1.x hosts:

access-list ABC permit tcp any host 192.168.1.11 eq 80
access-list ABC permit tcp any host 192.168.1.11 eq 443
access-list ABC permit tcp any host 192.168.1.12 eq 25
access-list ABC permit tcp any host 192.168.1.12 eq 110
access-list ABC permit tcp any host 192.168.1.13 eq 1521
access-list ABC permit tcp any host 192.168.1.3 eq 23

access-group ABC in interface outside

This ACL explicitly allows traffic to reach the private IPs that are being translated statically, enabling public access to services such as HTTP, HTTPS, SMTP, POP3, Oracle DB, and Telnet.

Static NAT is a cornerstone of any network that hosts services externally and ensures those services are reliably reachable via fixed public IPs.

 

Static PAT (Port Redirection)

Static PAT, also known as Port Redirection, enables the use of a single public IP address to provide access to multiple internal servers. This is typically deployed for devices in the DMZ and is accomplished by mapping different public-facing ports to specific internal IP/port pairs.

Rather than assigning a separate public IP for every internal service, Static PAT uses port numbers to differentiate traffic. This allows external users to connect to a single IP on different ports, each redirected to a different internal server or service.

A key use case for Static PAT is when an internal server listens on a non-standard port or when multiple services need to share a single public IP. For example, one server might handle Telnet on TCP/2323 and another might serve web traffic on TCP/80—all through the same public address.

 

Static PAT Configuration Examples

In modern ASA software, Static PAT is configured using object definitions combined with service keyword options to specify internal and external port numbers. Here’s how you can do it:

# Define the public IP object
object network globalIP
host 100.1.2.99

# Define the internal server
object network R2
host 10.2.2.2

# Create static PAT for Telnet using port redirection
nat (inside,outside) static globalIP service tcp telnet 23 2323

In this case, an external connection to TCP port 23 on 100.1.2.99 is redirected to TCP port 2323 on 10.2.2.2.

Another example using standard port mapping without redirection:

object network WWW1
host 192.168.1.11
nat (dmz,outside) static 192.1.20.5 service tcp 80 80

This configuration makes 192.168.1.11 accessible from the internet on TCP port 80 using the public IP 192.1.20.5. The external and internal ports are the same, but using service tcp makes it clear and allows flexibility if redirection is needed in the future.

 

When to Use Static PAT

Static PAT is the ideal solution when:

• You have limited public IP space and need to expose multiple services.
• Internal servers need to be externally reachable but are not listening on standard ports.
• You require port-specific control and visibility in NAT policy.

This approach is common in small to medium-sized DMZ designs, hosted services environments, and anywhere granular NAT control is required.

 

Identity NAT

Identity NAT is a special type of NAT where an address is translated to itself. This technique is generally used when you have public IP addresses statically assigned to internal devices, and those devices cannot tolerate changes in addressing due to NAT. It effectively exempts specific traffic from being NAT’d, which is especially critical in scenarios like remote access VPNs, where consistent end-to-end addressing is required.

According to Cisco’s configuration guidance:

“You might have a NAT configuration in which you need to translate an IP address to itself. For example, if you create a broad rule that applies NAT to every network, but want to exclude one network from NAT, you can create a static NAT rule to translate an address to itself. Identity NAT is necessary for remote access VPN, where you need to exempt the client traffic from NAT.”

This is useful in environments where broad NAT rules exist, but exceptions are required for specific subnets or hosts, either for compatibility, policy, or visibility reasons.

 

Identity NAT Configuration Example

To exempt a specific host from NAT, you would configure the following:

object network MF
host 192.1.100.5
nat (dmz,outside) static 192.1.100.5

This statement ensures that the host 192.1.100.5 is not translated—traffic to and from this host remains untouched by NAT rules, preserving its identity on the network.

For group-based identity NAT, which is common in large-scale or VPN deployments, the configuration might look like this:

object-group network DMZ-INTERNAL
network-object 200.0.0.0 255.255.255.0

object network DMZ
subnet 200.0.0.0 255.255.255.0
nat (dmz,outside) static DMZ-INTERNAL

This configuration prevents NAT translation for the entire 200.0.0.0/24 subnet by statically mapping it to itself. It’s handy when multiple internal devices with public IPs need to communicate without interference from NAT, or when split-tunnel VPNs need to avoid address conflicts.

With Identity NAT, you gain surgical control over when NAT is applied and when it’s intentionally bypassed. This ensures compatibility with legacy systems, remote VPN clients, or externally visible services that must retain fixed addresses.

 

Destination NAT

Destination NAT is used in scenarios where internal servers (often in the DMZ) do not have a default gateway and need to communicate using NATed destination addresses. This allows traffic to flow correctly without needing to change the server’s gateway, as the ASA rewrites the destination IP before delivering the packet to the internal host.

A classic use case is when a device in the DMZ needs to send traffic to a public IP, but you want the ASA to rewrite that destination to an internal IP (since the DMZ host has no route to the outside world). Destination NAT solves this by translating the destination IP address as the packet traverses the ASA from outside to inside.

 

Example Configuration

Let’s say you want traffic destined for 199.1.1.1 to be redirected to a DMZ host at 192.168.1.79. You’d configure:

object network H199
host 199.1.1.1
nat (outside,dmz) static 192.168.1.79

This tells the ASA to intercept traffic going to 199.1.1.1 and redirect it to 192.168.1.79 before it enters the DMZ.

 

Advanced Use: Twice NAT

Twice NAT allows simultaneous translation of source and destination addresses. This is useful in complex deployments involving legacy applications, routing constraints, or isolated network segments where both source and destination IPs must be altered.

Here’s how to configure it:

# Define internal and external objects
object network MF
host 192.168.1.45

object network MF-X
host 192.1.20.31

object network RC
host 111.1.1.1

object network RC-X
host 192.168.1.98

# NAT both source and destination
nat (dmz,outside) source static MF MF-X destination static RC RC-X

This rule says: when MF (internal client) communicates with RC (remote server), translate the source IP to MF-X and the destination IP to RC-X.

You can also configure classic static NAT as part of Twice NAT:

object network SRV
host 10.2.2.2
nat (dmz,outside) static 100.2.2.2

And to reverse the mapping for return traffic:

nat (outside,dmz) source dynamic any 10.2.2.99 destination static 100.2.2.2 10.2.2.2

This rule ensures that when a device outside tries to reach 100.2.2.2, it is redirected to the internal server at 10.2.2.2. At the same time, the ASA dynamically handles the return path, mapping the source as needed to keep the communication symmetrical.

 

NAT Control

In Cisco ASA, NAT Control serves as a safety net mechanism, essentially functioning like a catch-all or blackhole rule for NAT. It ensures that any traffic not explicitly allowed by your NAT policies is automatically dropped. This approach helps enforce strict translation boundaries and prevents unintentional or unauthorized NAT behavior.

Without such a rule, stray or misrouted traffic might pass through without a matching NAT entry, potentially resulting in security gaps or broken communication flows. By defining a final NAT rule that deliberately blackholes unmatched traffic, you can guarantee that only explicitly permitted sessions are translated and forwarded.

Sample NAT Control Rule

You can configure a catch-all rule using an object that represents 0.0.0.0 (essentially null routing any unmatched destination):

object network ZERO
host 0.0.0.0

nat (inside,outside) after-auto source dynamic any ZERO

This configuration uses the after-auto keyword to ensure the rule is evaluated after all standard Auto NAT rules. If no previous NAT rule applies to the session, the ASA uses this final rule, effectively blackholing the connection by translating it to a non-routable or unreachable IP (0.0.0.0).

This type of NAT control is especially useful in highly regulated environments where strict NAT enforcement is critical, such as financial, medical, or government networks.

 

Manual NAT II

Manual NAT, also known as Twice NAT, offers the most flexibility in Cisco ASA NAT configuration. It allows you to define NAT rules with precision—placing them at the top or bottom of the NAT processing order, and enabling full control over both source and destination translation within a single rule. This level of control makes it ideal for complex use cases like overlapping networks, advanced filtering policies, or tightly scoped NAT exceptions.

One of the biggest advantages of Manual NAT is visibility. When a Manual NAT rule is configured, you’ll see its static entry in the xlate table, along with hit counts showing how frequently the rule is used. You can also monitor NAT behavior using:

• show conn – Displays the connection table, including NAT translations
• debug nat – Offers real-time debugging (though resource-intensive)
• show log – If you enable logging at level 7, you can troubleshoot recent NAT connections without enabling debugging

In addition to translation flexibility, Manual NAT rules allow you to stack logic, combining source and destination objects into one rule. This makes it far more powerful than Object NAT, which only allows single-directional translation per object.

 

Best Practices for Manual NAT

When defining Manual NAT rules, order matters. ASA processes NAT rules from top to bottom, so it’s crucial to place the most specific NAT rules at the top to ensure they match before broader, general rules. This is especially important in environments with multiple overlapping NAT scenarios.

Parameters Available for Manual NAT
Cisco ASA provides multiple object types for use in Manual NAT statements:

• object-group network name – Defines multiple networks or host IPs; useful for grouped policies
• object network name – Used for a single host, subnet, or IP range
• object service name – Allows filtering based on service/port, enabling port-level NAT control

Manual NAT brings unmatched flexibility, especially in large or multi-tenant environments where precision NAT behavior is essential. Whether you’re deploying advanced translation strategies or just need to override default NAT behavior for a specific use case, Manual NAT is the tool of choice.

 

Static Manual NAT Example

To illustrate how Manual NAT can be used for static one-to-one address translation, let’s walk through a common scenario. Imagine you have an internal server in the DMZ with IP 200.0.0.10 that needs to be mapped to a different public-facing IP, 100.0.0.5. Rather than using standard Object NAT, you implement this using Manual Static NAT for greater control and visibility.

Configuration Steps

First, define both the internal and mapped address objects:

object network DMZ-SRV
host 200.0.0.10

object network MAP-SRV
host 100.0.0.5

Then, in global configuration mode, apply the static mapping using a source NAT rule:

nat (dmz,outside) source static DMZ-SRV MAP-SRV

This statement tells the ASA to translate the source address of any packet coming from the DMZ to MAP-SRV (100.0.0.5) when sending traffic to the outside. Because it’s a static translation, this mapping is persistent and always available in the NAT and xlate tables—perfect for services that must always be reachable externally without requiring a session to initiate the entry.

With this example, you’ve now seen how Static Manual NAT can be configured using flexible object definitions and inserted at precise points in the NAT rule hierarchy. This method is powerful for use cases where source IP translation must remain consistent, and where interface directionality plays a key role in traffic flow.

 

Network Manual Static NAT

While the previous example covered host-to-host static mapping, Manual NAT can also be applied at the network level—mapping entire subnets between interfaces. This is known as Network Manual Static NAT, and it’s commonly used when multiple internal hosts must appear externally as part of a mapped public subnet.

This form of NAT ensures a persistent, one-to-one mapping between each IP address in the private subnet and a corresponding IP in the public subnet. It’s particularly useful in multi-tenant or service provider environments where you need deterministic mappings and consistent translation across a range of clients or servers.

Configuration Example

Let’s say you want to translate the internal subnet 10.1.100.0/24 to a public-mapped subnet 100.0.0.128/25. You would define the objects as follows:

object network LAN
subnet 10.1.100.0 255.255.255.0

object network MAP-OUTSIDE
subnet 100.0.0.128 255.255.255.128

Then apply the static NAT using this command:

nat (inside,outside) source static LAN MAP-OUTSIDE

This command instructs the ASA to perform a static one-to-one mapping between each address in the LAN subnet and its corresponding address in the MAP-OUTSIDE subnet. For example, 10.1.100.5 would map to 100.0.0.133, and so on—preserving order and enabling reverse NAT (outside-to-inside) as needed.

This approach ensures that inbound and outbound traffic maintains a consistent mapping and is essential when dealing with overlapping address spaces, inter-organization routing, or regulatory constraints on IP addressing.

 

Dynamic Manual NAT

Dynamic Manual NAT allows administrators to configure many-to-many translations between private and public IP ranges using manual NAT rules. This method combines the flexibility of Manual NAT with the dynamic nature of address assignment—ideal for scaling outbound traffic across a NAT pool, while still maintaining full control over rule placement and matching behavior.

Unlike Object NAT, which places rules automatically in Section 2 of the NAT table, Dynamic Manual NAT rules can be inserted explicitly in Section 1 or Section 3, letting you prioritize or deprioritize them as needed. This is especially helpful when you’re layering NAT rules with varying levels of specificity or handling overlapping address spaces.

Configuration Example

In this example, we’re translating traffic from the internal subnet 10.1.100.0/24 to a dynamic pool of public IPs ranging from 100.0.0.15 to 100.0.0.20. Here’s how it’s set up:

object network LAN
subnet 10.1.100.0 255.255.255.0

object network NATPOOL
range 100.0.0.15 100.0.0.20

Then, apply the NAT rule in global configuration mode:

nat (inside,outside) source dynamic LAN NATPOOL

This command instructs the ASA to dynamically allocate a public IP from the NATPOOL range to internal hosts in the LAN subnet as connections are established. Each internal client receives a temporary public IP from the pool, and the xlate table is populated only while sessions are active.

This form of NAT is ideal when you want internal users to appear with distinct public identities but don’t want to statically bind each address ahead of time. It provides load distribution, flexibility, and NAT entry visibility—making it a go-to strategy for medium to large-scale outbound access control.

 

Manual PAT

Manual PAT (Port Address Translation) allows you to dynamically translate a group of internal IP addresses to a single external IP, with each session distinguished by its source port. Unlike Object NAT, where translation is tightly coupled to individual objects, Manual PAT provides greater flexibility, especially in rule ordering, specificity, and exception handling.

This type of PAT is configured manually in the global NAT rule table and can be placed after Auto NAT using the after-auto keyword, making it ideal as a fallback translation rule or a catch-all for unmatched internal traffic. This ensures that only traffic not matched by earlier NAT policies will fall through and be handled by this dynamic translation.

Configuration Example

Suppose we want to allow users from an internal LAN (10.1.100.0/24) to access the internet using a single public IP address (100.0.0.5). We configure the following objects:

object network OUTSIDE
host 100.0.0.5

object network LAN
subnet 10.1.100.0 255.255.255.0

Then, we apply the dynamic PAT rule:

nat (inside,outside) after-auto source dynamic LAN OUTSIDE

This rule dynamically translates the source IPs in the LAN subnet to the IP 100.0.0.5, while using unique source port numbers for each connection to maintain session separation. By placing the rule after-auto, you ensure that it only applies if no higher-priority Auto NAT or Manual NAT rule matches first.

This form of NAT is highly effective as a default policy for outbound traffic, where conserving public IP space is essential but basic one-to-many internet access must be preserved.

 

Manual Destination NAT

Manual Destination NAT is used when you need to translate the destination IP address of packets—typically in cases where internal devices access services hosted by external partners or in B2B environments requiring controlled IP redirection. This form of NAT is especially useful when integrating with third-party systems that expect traffic to be directed at specific IP addresses, but where internal routing or policy requires a different path.

By configuring Manual Destination NAT, you explicitly define how destination IP addresses should be rewritten as packets leave the ASA. This technique works well for applying consistent NAT behavior across trusted partner communications or where a certain internal IP must always represent a given external entity.

Configuration Example

Let’s say we have a partner system at IP 100.11.11.22 that needs to be accessed as if it were 10.1.100.15 on the internal network. We configure the following objects:

object network MAP-PARTNER1
host 10.1.100.15

object network PARTNER1
host 100.11.11.22

Then we apply the Manual Destination NAT rule in global configuration mode:

nat (inside,outside) after-auto source dynamic any interface destination static MAP-PARTNER1 PARTNER1

This statement accomplishes the following:

• Any source can initiate traffic (source dynamic any)
• The source will be PAT’d using the firewall’s interface IP
• The destination IP 100.11.11.22 will be translated to 10.1.100.15, allowing internal resources to access the partner system through a NAT mapping

Using after-auto ensures this rule is applied after all automatic NAT rules, acting as a controlled exception for a specific destination redirection pattern.

This strategy gives you tight control over external service access and can be crucial when dealing with overlapping address space, vendor-provided IP restrictions, or NAT-sensitive legacy protocols.

 

Identity NAT with Source and Destination Specified

In certain scenarios, you may want to exempt specific traffic from NAT entirely—not just based on source IP, but also based on the combination of source and destination. This is where Identity NAT with both source and destination specified comes into play. It’s particularly useful when dealing with trusted networks, site-to-site VPN tunnels, or sensitive B2B communications that must preserve IP identity for compliance or application compatibility.

This type of Identity NAT explicitly defines that traffic between a known source and known destination should not be NAT’d at all, even if general NAT rules apply to everything else. It provides granular control while maintaining the ability to log and manage the rule just like any other NAT statement.

Configuration Example

In the following example, traffic from the DMZ network (200.0.0.0/8) to the partner network (100.22.22.0/8) is excluded from NAT:

object network DMZ
subnet 200.0.0.0 255.255.255.0

object network PARTNER2-NETWORK
subnet 100.22.22.0 255.255.255.0

nat (dmz,outside) 1 source static DMZ DMZ destination static PARTNER2-NETWORK PARTNER2-NETWORK

This rule tells the ASA: if traffic comes from the DMZ subnet and is destined for the PARTNER2-NETWORK, do not translate the source or destination IP. It’s an identity mapping that overrides general NAT behavior for this specific traffic pair.

Extended Options

Cisco ASA provides several useful options to enhance the rule’s behavior:

• description – Adds a human-readable label for clarity.
• inactive – Temporarily disables the rule without deleting it.
• net-to-net – Enables identity NAT for both IPv4 and IPv6 endpoints.
• no-proxy-arp – Prevents ASA from answering ARP requests on the egress interface for these IPs.
• route-lookup – Forces a route lookup before applying the NAT rule.
• service – Allows specification of service-based NAT conditions (e.g., port-specific).
• unidirectional – Enables one-way NAT exemption (in one direction only).

This flexibility makes Identity NAT ideal for precise, policy-driven routing where translation must be deliberately bypassed.

 

Manual Twice NAT

Let’s explore Manual Twice NAT, one of the most flexible and precise NAT configurations on Cisco ASA. Unlike Object NAT, which only modifies one side of a connection (typically the source), Twice NAT gives you full control over both source and destination translation within a single rule. This is especially useful for complex topologies involving overlapping IP addresses, B2B links, and asymmetric routing conditions.

Configuration Process

To implement Manual Twice NAT, you must first define objects for all endpoints involved—both the original (pre-NAT) and translated (post-NAT) IPs. Here’s an example setup:

object network R3-D
host 192.168.1.3

object network R3-O
host 192.1.20.20

object network H199-O
host 199.1.1.1

object network H199-D
host 192.168.1.79

In this scenario:

• R3-D is the internal real IP of the source.
• R3-O is the IP address to which it will be translated.
• H199-D is the real destination address.
• H199-O is the translated address the destination should appear as.

Next, you define the NAT rule that translates both source and destination:

nat source static R3-D R3-O destination static H199-D H199-O

This rule means:

When traffic from 192.168.1.3 (R3-D) to 192.168.1.79 (H199-D) passes through the ASA, translate the source to 192.1.20.20 (R3-O) and the destination to 199.1.1.1 (H199-O).

This level of control is key for handling inter-company traffic, lab environments, or IP overlap situations where traditional NAT fails to provide the necessary flexibility.

 

Manual Identity NAT with Just Source

To wrap up the deep dive into NAT on Cisco ASA, let’s take a look at a simple but highly useful variation: Manual Identity NAT with only the source specified. This is especially relevant when you need to exempt certain traffic from being NATed, such as internal loopback addresses or specific interfaces used for control plane traffic.

Identity NAT maps an IP address to itself, effectively telling the firewall to bypass NAT for this traffic. It’s commonly used in remote access VPNs, loopback interfaces, or when inter-zone communication must remain untranslated for routing, logging, or policy enforcement reasons.

Configuration Example

To configure this, define the object for the source IP you want to exempt:

object network LOOPBACK2
host 10.1.100.37

Then apply the NAT rule:

nat (inside,outside) source static LOOPBACK2 LOOPBACK2

This statement ensures that any packet sourced from 10.1.100.37 will retain its IP as it transits the firewall, no address translation occurs. This is particularly useful when the destination expects the original source IP, or when troubleshooting requires consistent end-to-end addressing.

By using identity NAT with just the source defined, you’re simplifying policy control and enabling transparency across firewall boundaries without breaking routing or application expectations.

 

NAT Exempt: Preserving VPN Integrity with Manual NAT

In environments where two sites are connected via VPN over the internet, it’s common to have existing Port Address Translation (PAT) configured on the ASA’s outside interface. However, this becomes problematic when VPN traffic is NATed before it is encrypted—this breaks the tunnel. To prevent this, traffic between the internal networks of the two VPN peers must be explicitly exempted from NAT.

For example, if your local network is 10.1.1.0/24 and your remote peer network is 10.2.2.0/24, you need to configure NAT exemption to ensure traffic flows between them without being translated. This is where manual NAT exemption comes into play.

The recommended approach is to use manual NAT rules to explicitly bypass NAT for VPN-bound traffic. This involves configuring both source and destination identity mappings:

nat (inside,outside) source static LAN1 LAN2
nat (inside,outside) destination static LAN2 LAN2

In this configuration:

• LAN1 represents the local subnet (10.1.1.0/24)
• LAN2 represents the remote subnet (10.2.2.0/24)

These identity NAT rules tell the ASA to leave the source and destination IPs untouched as packets flow between these two networks. This ensures the traffic is encrypted with its original addresses intact, maintaining VPN integrity and allowing proper decryption and routing on the other side.

NAT exemption is essential for ensuring encrypted VPN traffic does not get unintentionally altered by NAT rules intended for general internet-bound traffic.

 

IPv6 NAT: Configuring Static Translation

As IPv6 adoption continues to grow, so does the need to support Network Address Translation in dual-stack and IPv6-only environments. While NAT is not generally needed in pure IPv6 networks due to the vast address space, it’s still commonly used in scenarios involving overlapping address spaces, privacy requirements, or policy enforcement between internal and external IPv6 zones.

In Cisco ASA, IPv6 Static NAT provides the ability to map one IPv6 address to another in a 1:1 static translation, similar to traditional IPv4 static NAT. The configuration process follows the familiar object-oriented NAT syntax used throughout ASA.

To configure IPv6 Static NAT:

1. First, define the source and translated IPv6 addresses using object network definitions:

object network obj1-name
host ipv6-address

object network obj2-name
host ipv6-address

2. Then, apply the static NAT rule using:

nat (inside,outside) source static obj1 obj2

This command sets up a static one-to-one mapping between obj1 (the internal IPv6 host) and obj2 (the external representation). This setup is useful in scenarios where you need to expose a specific IPv6 host to the outside world with a consistent, translated address or to resolve address overlap in B2B interconnections.

As always, it’s important to verify your NAT rules with show nat detail and ensure traffic is matching correctly without unintended overrides from other NAT statements.

 

IPv6 Dynamic NAT: Translating with Address Pools

Continuing with IPv6 NAT configurations on Cisco ASA, IPv6 Dynamic NAT provides flexibility when you need to map internal clients to a range of global IPv6 addresses. This is especially useful when multiple devices from the inside LAN need outbound access through unique or shared external IPv6 addresses without relying on one-to-one mappings.

To implement IPv6 Dynamic NAT, follow these steps:

1. Define the inside LAN subnet using an object:

object network obj1
subnet x:x:x::x/x

This object represents your internal IPv6 range.

2. Define the address pool to which internal addresses will be translated:

object network obj2
range x:x:x::x x:x:x::xx

This object defines the pool of available IPv6 addresses for dynamic translation.

3. Create the NAT rule that links the two objects:

nat (inside,outside) source dynamic obj1 obj2

This dynamic NAT rule tells the ASA to translate any traffic from the inside subnet defined in obj1 to a dynamic address pulled from the pool defined in obj2. This method ensures address reuse is minimized while providing scalable address translation for large networks.

Be sure to monitor NAT behavior using show nat and verify translation entries with show xlate. As IPv6 NAT is typically used only when business or technical constraints require it, validate that dynamic NAT aligns with your architecture’s intent and doesn’t conflict with global IPv6 best practices.

 

IPv6 PAT: Overloading with Interface-Based Translation

We will next explore IPv6 Port Address Translation (PAT), commonly referred to as overload. While PAT is not typically needed in IPv6 environments due to the abundance of address space, it can still be required in specific scenarios, especially during transitional deployments or when dealing with legacy systems and edge NAT boundaries.

To configure IPv6 PAT using the interface IP address as the translation source, you can define it directly with a general catch-all rule:

nat (inside,outside) source dynamic any pat-pool interface ipv6

This configuration applies to all inside IPv6 sources and translates them to the outside interface’s IPv6 address using PAT. This is a quick and broad approach to ensure all traffic is NATed when more granular control isn’t needed.

Alternatively, for a more refined method using defined network objects, follow these steps:

1. Define the source object:

object network obj1
subnet x:x:x::x/x

2. Apply the NAT rule using PAT:

nat (inside,outside) source dynamic obj1 pat-pool interface ip

This object-based approach is more scalable and cleaner, especially when managing multiple NAT rules. It also allows administrators to apply NAT policies with precision and consistency across different parts of the network.

Remember, while PAT is less common in IPv6 due to the availability of global addresses, understanding how to configure it remains essential for mixed environments and compliance with specific business or security requirements.

 

IPv6 Static PAT: Port-Level Translation for IPv6 Hosts

In specialized IPv6 deployments, you may need to perform Static Port Address Translation (Static PAT) to map specific internal ports to externally visible ones—similar to traditional IPv4 port forwarding. Cisco ASA supports this with IPv6 by allowing static bindings between source addresses and ports using defined service objects.

To begin, you’ll first create both a network object and a corresponding service object. Here’s how:

object network obj1
host x:x:x::x

This defines the internal IPv6 host that will be mapped.

Next, create a service object specifying the source port:

object service srv-obj1
service tcp source eq num

This identifies the TCP service (e.g., port 80 for HTTP or 443 for HTTPS) to be statically translated.

With those objects created, you can configure the NAT rule:

nat (inside,outside) source static obj1 interface ipv6 service srv-obj1

This line tells the ASA to translate traffic from the specified IPv6 host and source port to the outside interface, preserving the port mapping. This is particularly useful for exposing specific internal services to the public IPv6 internet while maintaining tight control over what is exposed.

This approach enables granular IPv6 NAT rules where only selected services are reachable from outside, improving both security and manageability.

 

IPv6 Twice NAT: Mapping Both Source and Destination in One Rule

IPv6 Twice NAT allows you to simultaneously translate both the source and destination addresses of a packet using a single NAT rule. This is useful in complex IPv6 deployments—such as when translating internal networks for VPN peers or cloud services where address overlap or policy-based routing is involved.

To implement IPv6 Twice NAT, begin by defining your inside and outside network objects:

object network obj1
subnet x:x:x::x/x

object network obj2
subnet x:x:x::x/x

These objects represent the internal source network (obj1) and the external destination network (obj2) that will be used in the NAT mapping.

Next, configure the Twice NAT rule using both dynamic and static NAT in one statement:

nat (inside,outside) dynamic any pat-pool obj1 destination static obj2 obj2

This command dynamically translates the source address using the obj1 PAT pool while simultaneously performing static NAT on the destination to obj2. It ensures that communication is allowed only between the translated source and the translated destination—ideal for tightly controlled communication scenarios.

Twice NAT in IPv6 contexts brings the same precision and control as in IPv4, enabling dual-translation logic that’s especially relevant when integrating third-party networks or tunneling services.

 

IPv6 Identity NAT: Preserving Original IPs in Specific Flows

IPv6 Identity NAT is used when you want to explicitly preserve both the source and destination IP addresses across a NAT boundary. This is useful in scenarios like VPN configurations, where traffic between specific networks should be exempt from translation but still require NAT rules to exist for policy or routing logic.

To implement IPv6 Identity NAT, start by defining your source and destination network objects:

object network obj1
subnet x:x:x::x/x

object network obj2
subnet x:x:x::x/x

Here, obj1 refers to the source network and obj2 to the destination network. These objects represent the IPv6 subnets that will communicate without undergoing translation.

Next, configure the NAT rule using the identity translation logic:

nat (inside,outside) source static obj1 obj1 destination static obj2 obj2

This statement tells the firewall: when traffic flows from obj1 to obj2, maintain the original IP addresses for both sides. Although the IPs aren’t translated, this configuration is still processed by the NAT engine, ensuring proper NAT exemption and policy compliance—especially when overlapping NAT rules might otherwise affect the traffic.

Identity NAT is a foundational tool in IPv6 policy control, particularly in tightly scoped, secure environments.

 

ASA NAT Troubleshooting

When troubleshooting NAT on Cisco ASA, two of the most informative commands are show nat interface and show xlate. These help determine how source IP addresses are translated as traffic enters or leaves specific interfaces, and whether NAT rules are being hit at all. This continuation explores these commands with an emphasis on interface-specific NAT visibility and dynamic PAT insights.

Reviewing show nat interface dmz1 detail

The show nat interface dmz1 detail command displays NAT policies applicable to the dmz1 interface, including source and destination interfaces, source objects, and their respective translations. It’s particularly useful when you’re trying to isolate why traffic isn’t being NAT’d as expected.

Example output:

Auto NAT Policies (Section 2)
1 (dmz1) to (any) source static obj_2.2.2.2-any 2.2.2.2
Source - Origin: 2.2.2.2/32, Translated: 2.2.2.2/32

2 (dmz1) to (Outside-1) source static obj_22.22.22.22-Outside-1 22.22.22.22
Source - Origin: 22.22.22.22/32, Translated: 22.22.22.22/32

...

6 (dmz1) to (Outside-1) source dynamic obj_192.168.203.60-70-Outside-1 POOL-OUT1
Source - Origin: 192.168.203.60-70, Translated: 200.100.34.60/30, 200.100.34.68/31, 200.100.34.70/32

...

10 (dmz1) to (Outside-1) source dynamic obj_192.168.203.0-Outside-1 200.100.34.203

Each entry shows:

• Source zone and destination zone
• NAT type (static or dynamic)
• The NAT object used
• The original IP or subnet
• The translated IP or subnet
• translate_hits and untranslate_hits counters (helpful to know if a rule is active)

This output confirms what translation (if any) is expected when traffic originates from a DMZ source.

 

Comparing to show nat interface dmz1 (non-detailed)

The non-detailed version of the show nat interface dmz1 command summarizes the same mappings but omits the actual hit counters. It’s useful for a quick policy overview, helping administrators ensure mappings are present without parsing detailed statistics.

This command gives:

• A listing of Auto NAT policies from Section 2 (i.e., object NAT rules)
• The objects and the NAT pools involved
• Destination interfaces (Outside-1, Outside-2, etc.)

This command is good for confirming configuration. But for active troubleshooting, especially verifying whether translations are occurring, show nat interface … detail provides far more actionable data.

 

Using show nat detail for Global NAT Rule Insight

Running show nat detail gives a complete look at NAT policies from all interfaces and zones. This is ideal when you’re unsure whether a rule even exists or want to compare hit counts between interfaces.

Sample excerpt:

(inside) to (outside) source dynamic LAN interface
translate_hits = 2, untranslate_hits = 5
Source - Origin: 10.4.100.0/24, Translated: 10.2.100.1/24

This highlights real usage, translate_hits and untranslate_hits show that traffic is hitting the NAT rule, and the translation mapping confirms where the traffic is going. If hit counts remain zero, the NAT rule may be misconfigured or unused.

 

Interpreting show xlate

The show xlate command displays real-time NAT translation sessions. This is one of the most powerful tools for confirming that traffic is actually being translated—and how.

Flags: D - DNS, e - extended, I - identity, i - dynamic, r - portmap,
s - static, T - twice, N - net-to-net

For example:

TCP PAT from inside:10.4.100.2/11659 to outside:10.2.100.1/11659
flags ri idle 0:00:12 timeout 0:00:30

This tells us that:

• Source address 10.4.100.2 (inside) was translated to 10.2.100.1 (outside)
• Port Address Translation (PAT) is in use (due to port 11659)
• The session is active with a short timeout

This command is essential for real-time NAT troubleshooting, especially when validating connection-specific behavior.

Together, show nat interface, show nat detail, and show xlate provide the visibility needed to troubleshoot NAT issues on Cisco ASA effectively. When used together:

• show nat interface … detail helps verify which rules apply and whether they’re being hit.
• show nat detail offers global insight across interfaces.
• show xlate gives proof of translation in live sessions.

Understanding how each NAT rule behaves in both configuration and runtime helps isolate broken NAT flows, misconfigured objects, or missing translations that could silently cause application failures.

Once your NAT policies are configured on the ASA, the next crucial step is validating that they work as intended. Cisco provides several built-in tools to verify NAT behavior and debug translation issues in real-time.

Testing NAT Policies with Packet Tracer

The packet-tracer command is a powerful diagnostic tool that simulates a packet as it traverses the ASA firewall. It allows administrators to test and verify NAT behavior without generating actual traffic. This is especially useful for confirming how a packet would be translated and whether the ASA would permit or deny it based on current policy.

Example syntax:

packet-tracer input outside tcp x.x.x.x port x.x.x.x

You can specify the interface, protocol, source IP, source port, destination IP, and destination port. The resulting output shows each firewall processing step—including NAT, ACLs, route lookup, and final disposition—making it easy to see if a NAT rule is misconfigured or missing.

 

Essential show Commands for NAT Troubleshooting

To complement the packet-tracer tool, several show commands provide runtime visibility into NAT rules, translations, and session activity:

• show run nat – Displays the current NAT configuration from the running config, including manual and object NAT.
• show run object – Lists all defined network objects. Useful for understanding what IPs or ranges are referenced in NAT rules.
• show conn [detail] – Displays connection table entries. The detail option reveals NAT translation and interface specifics.
• show nat [detail] – Offers a breakdown of NAT rules with statistics, including hit counters and translation details.
• show xlate – Shows current NAT translations in the xlate table. This is key for confirming whether active translations exist for a given source or destination.
• packet-tracer – As mentioned above, simulates a packet’s path through the ASA to test NAT, ACLs, and route handling.
• show log – Displays system log messages, which can include NAT translations, denies, and other debug information if logging is configured.

By combining packet-tracer with the show commands above, engineers gain full visibility into how the ASA is processing NAT traffic—from static mappings to dynamic PAT behavior. These tools are indispensable when troubleshooting issues like unidirectional traffic, failed translations, or asymmetric routing caused by missing NAT rules.