The ASA will always apply NAT based on the order of the NAT table (which is directly derived from the running configuration), which can be viewed with 'show nat detail'. It takes the packet and walks down the table in order of the entries programmed into the table, looking for the first rule that has a matching interface(s) and matching IP subnets/ports that apply to the packet in question; at that point the NAT translation is applied and further processing stops.
The NAT phase that you show highlighted reflects the stage where the packet's IP headers in an existing connection are re-written by NAT; it is not the exact phase where the egress interface selection is overridden by the translation table.
That order of operations slide is really quite simplified, and intentionally missing some steps because I just don't have time to go over the nuances of NAT during the general troubleshooting presentation that the picture was pulled from. On the next slide titled "Egress Interface", I do explain that NAT can override the global routing table for egress interface selection. This order of operations is somewhat "rough", and there are corner cases that can make the order of operations confusing.
The confusion here probably stems from the doubt about which comes first when selecting egress interfaces, routing or NAT. Hopefully with my explanation below, you'll have the missing pieces needed to fully explain why you see the seemingly inconsistent behavior. Please let me know what is unclear or contradictory about my explanation and I'll try and clear it up. I would also appreciate your suggestions on how to simply and clearly show these steps on a slide, so that I can improve how we deliver this information to our customers. Anyway, on to the explanation...
The short answer:
The NAT divert check (which is what overrides the routing table) is checking to see if there is any NAT rule that specifies destination address translation for an inbound packet arriving on an interface.
If there is no rule that explicitly specifies how to translate that packet's destination IP address, then the global routing table is consulted to determine the egress interface.
If there is a rule that explicitly specifies how to translate the packets destination IP address, then the NAT rule "pulls" the packet to the other interface in the translation and the global routing table is effectively bypassed.
The longer answer:
For the moment, ignore the diagram above. For the first packet in the flow arriving inbound on an ASA's interface (TCP SYN packet for example):
Step 1: un-translate the packet for the Security check: Check the packet's headers for matching NAT rules in the NAT table. If the rules apply to the packet, virtually un-NAT the packet so we can check it against the access policies of the ASA (ACL check).
Step 1.A: ACL Check: Check the un-translated packet against the interface ACL, if permitted proceed to step 2
Step 2: Check NAT-divert table for global routing table override: In this step the ASA checks the packet and determines if either of the following statements are true:
Step 2 check A: Did the packet arrive inbound on an interface that is specified as the global (aka mapped) interface in a NAT translation (this is most common when a packet arrives inbound on the outside interface and matches a mapped ip address or range, and is forwarded to an inside interface)?
-or-
Step 2 check B: Did the packet arrive inbound on an interface that is specified as the local (real) interface in a NAT translation that also has destination IP translation explicitly specified (this is seen in your first example, the case with your NAT exempt configuration for traffic from LAN to WAN bypassing translation)?
If either of these checks returns true, then the packet is virtually forwarded to the other interface specified in the matching NAT translation line, bypassing the global routing table egress interface lookup; Then, a subsequent interface-specific route lookup is done to determine the next-hop address to forward the packet to.
Put another way, Step 2 check B checks to see if the packet matches an entry in the NAT divert-table. If it does, then the global routing table is bypassed, and the packet is virtually forwarded to the other (local) interface specified in the nat translation. You can actually see the nat divert-table contents with the command 'show nat divert-table', but don't bother too much with it as it isn't very consumable and might be mis-leading.
Now lets refer to the specific example you outlined in your post; you said:
route ISP-1 0.0.0.0 0.0.0.0 1.1.1.1 1
route ISP-2 0.0.0.0 0.0.0.0 2.2.2.1 254
nat (LAN,ISP-1) after-auto source dynamic any interface
nat (LAN,ISP-2) after-auto source dynamic any interface
Now lets say that there is a connection coming from behind LAN interface with the source IP address 10.10.10.10 destined for 8.8.8.8 on destination port TCP/80. The flow chart would seem to indicate (with the above information/configuration in mind) that a NAT would be done before L3 Route Lookup?
The packet you describe will not match any nat-divert entries, and the egress interface selection will be performed based on the L3 routing table, which you have tested and confirmed. This is because the packet does not match Step 2 checks A or B.
It doesn't match Step 2 Check A because the packet did not arrive inbound on the mapped (aka global) interfaces ISP-1 or ISP-2 from the NAT config lines. It arrived inbound on the local (aka real) interface LAN.
It doesn't match Step 2 Check B because these NAT rules don't have destination IP address translation explicitly configured (unlike your LAN to WAN example)...therefore the ASA won't match a divert-table entry for the packet (actually you'll see a rule in the divert table, but it will have ignore=yes, so it is skipped).
Message was edited by: Jay Johnston
