Network Address Translation (NAT) order of operation in the PIX Firewall & ASA (9.1)

TCC_2 · ‎06-22-2009

Resolution

Scenario 1:

This is the sequence in which the translation commands are prioritized by the PIX Firewall:

nat 0 access-list (nat-exempt)
match against existing xlates
static statements
1. static nat with and without access-list (first match)
2. static pat with and without access-list (first match)
nat
nat access-list (first match)
1. Note: The nat 0 access-list command is not part of this command.
2. nat (best match)
  
  Note: When choosing a global address from multiple pools with the same NAT ID, this order is attempted:
  1. If the ID is 0, create an identity xlate.
  2. Use the global pool for the dynamic NAT.
  3. Use the global pool for the dynamic PAT.
Error

NAT 0 STATEMENT:
nat (inside_interface_name) 0

NAT 0 has two affects:
1. nat (inside_interface_name) 0 access-list 101
  
  This works exactly the same way as static, except it bypasses NAT. It does not require the connection to be initiated from the higher security interface before the host on the lower security interface can create a connection to the host on the higher security level interface.
2. nat (inside_interface_name) 0 0.0.0.0 0.0.0.0
  
  This bypasses NAT, but requires the host on the higher security interface to first initiate a connection to the host on the lower security interface before the host on the lower security interface can initiate
  a connection.

Scenario 2:

Problem:

User wants a router (887) behind ASA with a public address, to get to internet without been NATED from the ASA. Everything else is working

Setup:

10.0.0.0/8 0.0.0.0/0
| |
border router(877W) ---79.x.x.112/29----> Asa firewall ----79.x.x.120/29-----> router(887) ----------10.0.0.0/24---->client

The nat rules already applied are mentioned below:

1st

nat (inside,outside) source static inside-network inside-network destination static ALL ALL (not Working)

2nd

nat (inside,outside) source static DEFAULT-PAT-SOURCE DEFAULT-PAT-SOURCE destination static DEFAULT-PAT-SOURCE DEFAULT-PAT-SOURCE (Working)

3rd

nat (inside,outside) after-auto source dynamic DEFAULT-PAT-SOURCE interface destination static ALL ALL (Working)

object-group network ALL

network-object object ANY-0.0.0.0-1

network-object object ANY-128.0.0.0-1

object network ANY-0.0.0.0-1

subnet 0.0.0.0 128.0.0.0

object network ANY-128.0.0.0-1

subnet 128.0.0.0 128.0.0.0

object-group network DEFAULT-PAT-SOURCE

network-object object 172ari

network-object object 192ari

network-object object dekari

object network 172ari

subnet 172.16.32.0 255.255.255.0

object network 192ari

subnet 192.168.0.0 255.255.0.0

object network dekari

subnet 10.0.0.0 255.0.0.0

object network inside-network

subnet 79.x.x.120 255.255.255.248

Solution:

The boarder router also needs a route back to the 179.x.x.120/29 network.Anyway as user can see traffic is going through the firewall but the ISP is not routing back the traffic to you.

Make sure the border router(877W) has a route to the internal Public subnet.

User should implement below commands and should check the output.

cap capout interface outside match icmp host x.x.x.x (Internal router IP address) host 4.2.2.2
cap capin interface inside match icmp host x.x.x.x (Internal router IP address) host 4.2.2.2

Then ping to 4.2.2.2 from the router.

Commands used to check output:
show cap capin
show cap capout

Refer to these documents for more information on these commands: