ASA Identity NAT vs IOS NAT Exclusion for VPN Traffic

A branch keeps internet PAT and a site-to-site VPN on the same Cisco gateway, and the VPN stops working the moment NAT is added. The addresses inside the tunnel no longer match what the crypto ACL protects, or the peer sees translated addresses it has no route for. Cisco solves this in two different places: the ASA selects a NAT rule that maps an address to itself, while IOS keeps the flow out of a translation rule through an ACL deny. Both preserve the original addresses, and neither is a bypass of NAT processing. The difference matters when you have to prove which rule acted on a packet.

Record the flow before selecting a rule

Start by writing down the flow you expect to protect: original LAN source, remote destination, and the exact address pair the IPsec policy protects. Do that before you edit a rule, because the tuple tells you which classifier or NAT rule should have matched.

Then find the rule that actually matched, not the one you intended to match. On both platforms NAT is evaluated in an order, and an earlier rule can win before your exception is consulted. A correct-looking exemption that loses to another rule never supplies the expected packet to the protection policy. The symptom is identical to a missing exemption, which is why rule order has to be read before the configuration is changed.

ASA identity NAT is a rule, not a bypass

On the ASA, identity NAT is a NAT rule whose translated address equals the original. It is selected like any other rule and it still installs a translation entry, so the packet is not skipping NAT processing. What changes is that the addresses on the wire stay the same, which is what the IPsec policy needs.

nat (inside,outside) source static LAN-NET LAN-NET destination static REMOTE-NET REMOTE-NET

The rule's interfaces and its route-lookup setting have to match the forwarding design. A rule that maps the address correctly but is applied to the wrong interface pair will not be selected for the flow you care about. On releases that support it, route-lookup decides whether the translated packet is routed or the original destination is used, and that detail decides whether return traffic comes back through the tunnel. Copying a rule without its interface and lookup context is how a working config becomes a broken one.

Management access to the ASA itself is a separate case. If you use identity NAT for management traffic, the release-specific route-lookup requirement applies, and a broad exception copied from a VPN example will not fix SSH.

An IOS NAT ACL deny means not selected here

On IOS, internet NAT is driven by a source list, and that ACL is a classifier rather than a filter. A permit line selects traffic for translation by that rule; a deny line means the packet is not selected here. That deny is not an instruction to drop the packet the way a deny in an interface ACL is.

Not selected here is also narrower than never translated anywhere. Another NAT rule, a different interface, or a route-map can still translate the flow, so the whole NAT table has to be read. The packet also still needs a route, a crypto ACL that matches it, and permission at the actual access-control boundaries. NAT exemption removes one obstacle; it does not create the tunnel or open the firewall.

A minimal IOS arrangement puts the deny above the permit in the same list and points the overload rule at that list. The crypto ACL then protects the same pair the deny excludes from translation.

ip access-list extended NAT-ACL
 deny ip 10.10.0.0 0.0.0.255 192.0.2.0 0.0.0.255
 permit ip 10.10.0.0 0.0.0.255 any
ip nat inside source list NAT-ACL interface GigabitEthernet0/1 overload

One testable question for both models

Both models answer the same question: which rule matched this flow, and what addresses left the interface? Capture on the outside interface and compare the source address before and after the gateway. Then check the peer's view of the tunnel, because the SA can be up while the protected flow is being translated somewhere else.

On the ASA, show nat detail and the translation table; on IOS, show ip nat translations and the matching access list counters. A rule that never increments was never selected, which points at order, interface, or direction rather than at the crypto configuration.

Where the configuration usually goes wrong

The common failures are mechanical. The deny sits below the permit and never matches. The classifier is applied in the wrong direction, so the return flow is translated. The identity rule covers the right addresses but the wrong interface pair. The crypto ACL protects a subnet that no longer matches what the NAT rule presents.

Record the original and presented address pair next to the rule owner, so the next engineer can see why a classifier denies translation while the firewall permits the application. Keep that record with the change ticket, not in a personal note. Then re-run the flow after any NAT change, because rule order is part of the configuration even when the text of the rule is unchanged. A tunnel that comes up is not proof that the addresses survived; only the captured packet and the peer's decapsulated view are.