topic cisco asa traffic flow with destination nat in Network Security

cisco asa traffic flow with destination nat

secureIT — Tue, 12 Mar 2019 02:27:15 GMT

Hi Folks,

Can anybody comment on the below.

1. in source natting (inside users accessing internet), first the NAT will happen then the routing will happen. I agree with this..

2. in destination natting (outside users accessing inside server on public ip), what will happen first, NATTING or Routing. I am looking forward to hear an explanation.

regards

Rajesh

Re: cisco asa traffic flow with destination nat

Jouni Forss — Mon, 19 Aug 2013 06:35:57 GMT

Hi,

To my understanding when we look at a Dynamic PAT configuration for outbound traffic then the ASA will first check the routing table to determine what the egress interface is and where to forward the packet. And after that the NAT is applied according to the egress interface chosen.

If you have an Static NAT configured for some host and a connection is coming inbound then the ASA performs UN-NAT first which shows the egress interface chosen according to the NAT configuration.

- Jouni

Message was edited by: Jouni Forss

cisco asa traffic flow with destination nat

secureIT — Mon, 19 Aug 2013 06:54:48 GMT

Hey Thanks Jouni for the quick reply..

http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a0080ba9d00.shtml

--this says for outbound connection, NAT comes first and then Routing..

Can you please have a detailed study and update me. This being in my mind and browsing thru diff articles (let it be cisco or juniper), it gives diff answers. So far, i am assuming that for destination nat traffic Routing happens first and source natting traffic NAT happes first. I dont know how it is really working ??? May be someone from Cisco Can also comment on this..

Re: cisco asa traffic flow with destination nat

Jouni Forss — Mon, 19 Aug 2013 07:32:23 GMT

Hi,

I have always used the "packec-tracer" command to determine what is happening in a certain situation. And to my understanding there has been no change for the Source NAT between all the different software levels.

Source NAT

Route Lookup
ACL Check
Source NAT

Destination NAT

UN-NAT (NAT Chooses the egress interface)
ACL Check

The above is ofcourse for software levels 8.3 and above. In 8.2 and below the ACL Check and UN-NAT change order for Destination NAT.

I am not quite sure to what the Cisco document refers to (the one you linked) with the ordering or NAT and Route-Lookup. I am not sure how the ASA is supposed to choose the correct NAT to apply if it doesnt already know beforehand what the egress interface is for the traffic.

So lets say you have Dual ISP setup with ISP Failover. You have 2 Dynamic PAT configurations, one for each ISP. If the NAT was supposed to happen first, how does the ASA determine which Dynamic PAT configuration to use if it hasnt chosen the outbound interface for that packet.

Atleast this is how it seems to me.

- Jouni

Re: cisco asa traffic flow with destination nat

Jouni Forss — Mon, 19 Aug 2013 07:39:37 GMT

Also,

Here are some links (not official Cisco ones) that seem to make more sense to me

Flow chart:

http://ccie-or-null.net/2011/11/15/packet-flow-through-a-cisco-asa/

Check the NAT table later in this discussion:

https://learningnetwork.cisco.com/thread/46543

- Jouni

cisco asa traffic flow with destination nat

Jouni Forss — Mon, 19 Aug 2013 17:26:48 GMT

Hi,

Have checked some different documents from Cisco regarding this matter and it seems to me that the documents dont really match the "packet-tracer" output with regards to the order of NAT/Routing or I am just missing something.

If I were to believe the "packet-tracer" output blindly then I would say the following

If we have a packet incoming to some ASA interface and there is no NAT for the destination IP address, the ASA will look at its routing table to determine the egress interface and then the first matching NAT configuration for this source address.
If we have a packet incoming to some ASA interface and there IS a NAT for the destination IP address, the ASA will use the destination interface in the NAT configuration as the egress interface and use that interfaces routes to determine the nexthop.

But yet looking at the packet flow charts, they only mention the L2/L3 lookups at the very end of the chart.

- Jouni

cisco asa traffic flow with destination nat

secureIT — Tue, 20 Aug 2013 17:14:15 GMT

Hi Jouni,

Yes documents dont really match the "packet-tracer" output with regards to the order of NAT/Routing.

So i will have to blindly believe the cisco document as given below.

Src NAT >- session - acl - NAT - routing

Dst NAT >- session - acl - routing - NAT

http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a0080ba9d00.shtml
Can you let me know the difference between step 5 & 7 == both looks like the same.

regards

Rajesh

cisco asa traffic flow with destination nat

Jouni Forss — Tue, 20 Aug 2013 17:20:46 GMT

Hi,

I did send a PM through the Cisco Support Community to some Cisco employees about this discussion if they could clarify this issue with understanding the Cisco documentation.

I would be very interested to hear the specific of this also. Even though I know how the ASA behaves with regards to choosing the NAT configuration that will be applied and the egress interface that will be chosen I am having a hard time fitting that logic to what I read on the documents you linked.

Lets see if there is any reply from them. Perhaps I will send messages to some other people also if there is no reply.

- Jouni

cisco asa traffic flow with destination nat

secureIT — Tue, 20 Aug 2013 17:26:52 GMT

Thank you very much

Re:cisco asa traffic flow with destination nat

Anthony.Herman — Tue, 20 Aug 2013 17:39:32 GMT

5 is matching the rule prior to inspection.

6 is applying inspection

7 is modifying ip addressing per Nat rule.

Sent from Cisco Technical Support Android App

cisco asa traffic flow with destination nat

secureIT — Tue, 20 Aug 2013 18:07:13 GMT

Ok, is that 5 says, check the source and destination in NAT rules but dont apply

And 7 says, apply the nat translation for source/destination

Is that they are trying to convey ?

cisco asa traffic flow with destination nat

Jouni Forss — Tue, 20 Aug 2013 18:15:59 GMT

Hi,

It would seem logical to me atleast.

Though it still leaves me with a question about the L3 lookup.

The document seems to state that the translation will determine the egress interface. Yet if I have configured Dynamic PAT from one LAN interface to 2x WAN interface then the active default route determines which Dynamic PAT is applied.

So this kind of confuses me still.

- Jouni

cisco asa traffic flow with destination nat

Anthony.Herman — Tue, 20 Aug 2013 18:32:32 GMT

5 would be checking to see if a NAT rule exists in the config PRIOR to translation to reduce overhead I would assume. There is no point in performing inspection and afterwards dropping the traffic.

6 Is applying inspection engines (mpf)

7 is THEN applying the translation. (Rewriting IP headers)

I'm not sure where the confusion is here, all connections should be understood from the Ingress > Egress standpoint. The picture under the heading ASA Packet Process Algorithm explains it beautifully on http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a0080ba9d00.shtml

Re: cisco asa traffic flow with destination nat

Jouni Forss — Tue, 20 Aug 2013 18:41:41 GMT

Hi,

I am just wondering for example the following simple example (I ignored the typical "track" and "sla" configuration that would be normally used in this situation to have the automatic failover of the default route between the ISPs.)

interface GigabitEthernet0/0

nameif ISP-1

security-level 0

ip add 1.1.1.2 255.255.255.248

interface GigabitEthernet0/1

nameif ISP-2

security-level 0

ip add 2.2.2.2 255.255.255.248

interface GigabitEthernet0/2

nameif LAN

security-level 100

ip add 10.10.10.1 255.255.255.0

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

global (ISP-1) 1 interface

global (ISP-2) 1 interface

nat (inside) 1 10.10.10.0 255.255.255.0

So if we look at the document, it makes no mention of any L3 lookup except after applying the NAT configurations. In the above situation I would imagine there is a NAT that could apply for the LAN network to the direction of either ISP-1 or ISP-2.

So which ISP interfaces NAT configurations is applied if no decision egress interface has been made according to the routing table?

And if no routing table affects the NAT chosen, how exactly is the NAT chosen on the basis of the above 2 possibilities?

- Jouni

cisco asa traffic flow with destination nat

secureIT — Wed, 21 Aug 2013 09:59:15 GMT

Hi Anthony,

We were discussing on Destination-NAT traffic flow Vs Source-NAT.

In source-NAT, as per the link which you provided, NAT will happen before Routing. What about for Destination-NAT ?

regards

Rajesh. P

cisco asa traffic flow with destination nat

Jay Johnston — Wed, 21 Aug 2013 21:42:31 GMT

Hi all!

The topic being discussed here is one that sometimes causes confusion for ASA administrators. The general rule is that NAT translations will override the routing table when the ASA is determining the egress interface to forward the packet out of.

I've written a document that outlines this specific problem, as well as general NAT order of operations and some specific problems that we've seen customers hit with the NAT feature:

http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a0080c15911.shtml

Specifically, check out the section "Problem: A NAT rule diverts traffic to an incorrect interface"

http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a0080c15911.shtml#anc11

Also, if you don't mind, please provide comments on how useful you've found the article and what you think I can do to improve it.

Re: cisco asa traffic flow with destination nat

Jouni Forss — Wed, 21 Aug 2013 22:15:58 GMT

Hi Jay, thank you for replying to the discussion.

I do understand the point about a NAT configuration causing a inbound connection coming from one ASA interface to head out another interface on the basis of the interface configured in the NAT configuration (the UN-NAT phase)

object network LAN

subnet 10.10.10.0 255.255.255.0

object network REMOTE

subnet 192.168.10.0 255.255.255.0

nat (LAN,WAN) source static LAN LAN destination static REMOTE REMOTE

We could determine that incoming connection from the LAN to REMOTE would have its egress interface decided by the NAT configuration. And to my understanding after that decision the ASA would also do a L3 routelookup to where to forward the traffic.

If we added "route-lookup" keyword to the above NAT configuration, it would be ignored. (Provided the network REMOTE has a route on the ASA towards some other interface)

What I would like to get a clarification on is the below flow chart (click to enlarge)

According to the above we can see a mention of NAT before anything related to L3 Routelookup or Egress interface.

Now a situation where I cant match the logic in the above flow chart to the actual NAT operation

Lets say we have the following interface: LAN, ISP-1 and ISP-2

We have the following configurations

interface GigabitEthernet0/0

nameif ISP-1

security-level 0

ip add 1.1.1.2 255.255.255.248

interface GigabitEthernet0/1

nameif ISP-2

security-level 0

ip add 2.2.2.2 255.255.255.248

interface GigabitEthernet0/2

nameif LAN

security-level 100

ip add 10.10.10.1 255.255.255.0

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?

Which for me raises a questin on how exactly does the ASA choose the NAT/PAT configuration to be used (if there are multiple that apply to it like above) if there is no decision on the destination interface yet?

To me the operation seems more like (according to "packet-tracer") that the ASA first does a route lookup for the destination IP address and when this is found it applies the first matching NAT/PAT rule for those interfaces in question.

Could you elaborate a bit on the above situation? I can't help but think that I have just understood something horribly wrong even though I know how the actual traffic is forwarded in a live network.

- Jouni

Message was edited by: Jouni Forss (reordered posted content and edited some mistakes)

Re: cisco asa traffic flow with destination nat

Jay Johnston — Thu, 22 Aug 2013 04:12:30 GMT

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

cisco asa traffic flow with destination nat

Jouni Forss — Thu, 22 Aug 2013 07:33:22 GMT

Hi Jay,

Thank your for the great explanation. I mainly wanted some peace of mind that I had not completely understood something wrong about this matter.

My main problem sometimes when going through either Configuration Guides or Command References is that while they provide valuable information it seems that its hard to find very specific documents explaining some area of the ASA operation thoroughly.

Even though you mention that some of the NAT related things probably arent essential in everyday troubleshooting use, I wouldnt mind learning as much about the NAT operation as I can.

This is certainly something I will be planning to add to my NAT document when I have the time(which still requires a lot of additions/corrections/clarifications)

https://supportforums.cisco.com/docs/DOC-31116

As a final question, are there any publicly available documents/books that go through this process in depth? Or is there perhaps some certification related (CCNP or CCIE Security) books/material that go in depth to this subject? Or are all document of this sort internal Cisco documents/material?

Thank you again for answering the questions.

Endorsing the reply as I think it would be very helpfull for many people possibly running to issues with NAT/Routing

- Jouni

cisco asa traffic flow with destination nat

Jay Johnston — Thu, 22 Aug 2013 20:52:52 GMT

Some of these specifics are outlined in the configuration guide (see

http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/nat_overview.html#wp1245357)

but most people learn best by viewing specific examples and use cases.