3/8/2018 ASA order of operations (pre-8.3 and post 8.

3) - 46543 - The Cisco Learning Network

Home > CCIE Security Study Group > Discussions

19 Replies Latest reply: May 9, 2017 6:11 AM by Wasim

1 2

MIKIS Mar 9, 2013 4:15 PM

ASA order of operations (pre-8.3 and post 8.3)

This question is Not Answered.

Hello

Since I have seen a plethora of contradicting posts and documentation regarding the ASA order of operations,
I would like to clarify this topic regarding Routing, NAT, ACL on both pre-8.3 and post-8.3 ASA. I don't want to check
more features since I would like to clarify these 3 first that I consider the most basic.
Topology used for the testing:
1.1.1.1 R1 -----100.0.0.0/24------ INSIDE ASA1 OUTSIDE ------100.0.1.0/24-------- R2 2.2.2.2

Pre-8.3 ASA
The initial ASA configuration:
ASA1# sh run static
static (insidE,outside) 100.0.1.99 1.1.1.1 netmask 255.255.255.255

ASA1# sh run access-list

access-list INSIDE_IN extended permit ip host 1.1.1.1 host 2.2.2.2
access-list OUTSIDE_IN extended permit ip host 2.2.2.2 host 1.1.1.1
access-list OUTSIDE_IN extended permit ip host 2.2.2.2 host 100.0.1.99
ASA1# sh run access-group
access-group INSIDE_IN in interface inside
access-group OUTSIDE_IN in interface outside

Case 1 - source NAT

Without configuring any routing on ASA1
When I try to ping from 1.1.1.1 to 2.2.2.2 I see that the ACL INSIDE_IN doesn't get any hit counts.
Also packet-tracer output shows a failure due to missing routing without checking for ACL or NAT
(the Implicit ACL is not the ACL INSIDE_IN)
ASA1# packet-tracer input inside icmp 1.1.1.1 8 0 2.2.2.2

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow

Result:
input-interface: inside
input-status: up
input-line-status: up
Action: drop
Drop-reason: (no-route) No route to host

Conclusion 1:
Routing is checked before ACL and NAT.

I add routing on ASA1:

ASA1# sh run route
route insidE 1.1.1.1 255.255.255.255 100.0.0.1 1

https://learningnetwork.cisco.com/thread/46543 1/9
3/8/2018 ASA order of operations (pre-8.3 and post 8.3) - 46543 - The Cisco Learning Network
route outside 2.2.2.2 255.255.255.255 100.0.1.1 1

Now packet-tracer shows:

ASA1#packet-tracer input inside icmp 1.1.1.1 8 0 2.2.2.2

Phase: 1
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW

Phase: 2
Type: ROUTE-LOOKUP
...
in 2.2.2.2 255.255.255.255 outside

Phase: 3
Type: ACCESS-LIST
...
access-group INSIDE_IN in interface inside
access-list INSIDE_IN extended permit ip host 1.1.1.1 host 2.2.2.2
...

Phase: 6
Type: NAT
...
static (inside,outside) 100.0.1.99 1.1.1.1 netmask 255.255.255.255

Conclusion 2:
On pre-8.3 ASA for source NAT the order of operations is:
1. Routing
2. Inbound ACL
3. NAT

Case 2 - destination NAT (UN-NAT)

I remove again the 2 static routes:
ASA1(config)# no route outside 2.2.2.2 255.255.255.255 100.0.1.1 1
ASA1(config)# no route inside 1.1.1.1 255.255.255.255 100.0.0.1

I try to ping from 2.2.2.2 the 100.0.1.99 (NATed IP of 1.1.1.1)

The ping fails, but the ACL OUTSIDE_IN is getting hit counts although there is no routing towards 1.1.1.1
Also, note that only the ACE with destination 100.0.1.99 (post-NAT) gets hit counts. That means the ACL
is checked before the destination NAT (UN-NAT) and the routing:
access-list OUTSIDE_IN line 1 extended permit ip host 2.2.2.2 host 1.1.1.1 (hitcnt=0)
access-list OUTSIDE_IN line 2 extended permit ip host 2.2.2.2 host 100.0.1.99 (hitcnt=2)

Conclusion 3:
For destination NAT, the ACL is checked before routing. Also the ACL is checked before the NAT.

I add the static routes and now ping succeeds.

Packet-tracer shows:
ASA1#packet-tracer input outside icmp 2.2.2.2 8 0 100.0.1.99

Phase: 1
Type: FLOW-LOOKUP
...

Phase: 2
Type: UN-NAT
Subtype: static
...
static (inside,outside) 100.0.1.99 1.1.1.1 netmask 255.255.255.255
Untranslate 100.0.1.99/0 to 1.1.1.1/0 using netmask 255.255.255.255

Phase: 3
Type: ACCESS-LIST
...
access-list OUTSIDE_IN extended permit ip host 2.2.2.2 host 100.0.1.99

...

Phase: 6
Type: NAT

https://learningnetwork.cisco.com/thread/46543 2/9
3/8/2018 ASA order of operations (pre-8.3 and post 8.3) - 46543 - The Cisco Learning Network
Subtype: rpf-check
Result: ALLOW
Config:
static (inside,outside) 100.0.1.99 1.1.1.1 netmask 255.255.255.255
...

Phase: 8
Type: ROUTE-LOOKUP
...
found next-hop 100.0.0.1 using egress ifc inside
adjacency Active
next-hop mac address cc00.0d18.0000 hits 2

Conclusion 4:
On pre-8.3 ASA with destination NAT the order of operations is:
1. ACL
2. UN-NAT (destination NAT)
3. Routing

Post 8.3 ASA - (8.4(2) on GNS3)

Same topology:
1.1.1.1 R1 -----100.0.0.0/24------ INSIDE ASA1 OUTSIDE ------100.0.1.0/24-------- R2 2.2.2.2

ASA initial config (In configured a Manual Static NAT (Twice NAT) same as before (1.1.1.1 will be
translated to 100.0.1.99 as it goes from inside to outside):
ASA1# sh run object
object network R1_REAL_1.1.1.1
host 1.1.1.1
object network R1_NAT_100.0.1.99
host 100.0.1.99
nat (inside,outside) source static R1_REAL_1.1.1.1 R1_NAT_100.0.1.99

ASA1# sh run access-list

access-list INSIDE_IN extended permit ip host 1.1.1.1 host 2.2.2.2
access-list OUTSIDE_IN extended permit ip host 2.2.2.2 host 1.1.1.1
access-list OUTSIDE_IN extended permit ip host 2.2.2.2 host 100.0.1.99
ASA1# sh run access-group
access-group INSIDE_IN in interface inside
access-group OUTSIDE_IN in interface outside

Case 1
I try to ping from R1 (1.1.1.1) to R2 (2.2.2.2). Ping fails since ASA1 doesn't have routing towards
2.2.2.2. The ACL INSIDE_IN doesn't get any hit-counts.
Conclusion 5:
As with pre-8.3 ASA, the routing is checked before the inbound ACL and the NAT.

packet-tracer verifies this:

ASA1# packet-tracer input inside icmp 1.1.1.1 8 0 2.2.2.2

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Result:
input-interface: inside
input-status: up
input-line-status: up
Action: drop
Drop-reason: (no-route) No route to host

I add static routes on ASA1:

ASA1(config)# route inside 1.1.1.1 255.255.255.255 100.0.0.1
ASA1(config)# route outside 2.2.2.2 255.255.255.255 100.0.1.1

Now ping succeeds. Packet-tracer shows:

ASA1#packet-tracer input inside icmp 1.1.1.1 8 0 2.2.2.2

Phase: 1

https://learningnetwork.cisco.com/thread/46543 3/9
3/8/2018 ASA order of operations (pre-8.3 and post 8.3) - 46543 - The Cisco Learning Network
Type: ROUTE-LOOKUP
...
in 2.2.2.2 255.255.255.255 outside

Phase: 2
Type: ACCESS-LIST
...
access-group INSIDE_IN in interface inside
access-list INSIDE_IN extended permit ip host 1.1.1.1 host 2.2.2.2
Additional Information:

...

Phase: 5
Type: NAT
...
nat (inside,outside) source static R1_REAL_1.1.1.1 R1_NAT_100.0.1.99
Additional Information:

Conclusion 6:
As with pre-8.3 ASA, the order of operations in case of source NAT is the same:
1. Routing
2. Inbound ACL
3. NAT

Case 2
I remove again the 2 static routes:
ASA1(config)# no route outside 2.2.2.2 255.255.255.255 100.0.1.1 1
ASA1(config)# no route inside 1.1.1.1 255.255.255.255 100.0.0.1

I try to ping from 2.2.2.2 the 100.0.1.99 (NATed IP of 1.1.1.1).

Although there is no routing on ASA1, the ACL OUTSIDE_IN gets hit-counts. Note that in this case the
ACE with the 1.1.1.1 (pre-NAT) IP gets hit-counts. This is the expected behavior since on post-8.3 ASA
one of the big differences compared to the pre-8.3 ASA is that the ACL has to have the real IP (pre-NAT) instead of the
mapped IP (post-IP)
access-list OUTSIDE_IN line 1 extended permit ip host 2.2.2.2 host 1.1.1.1 (hitcnt=2)
access-list OUTSIDE_IN line 2 extended permit ip host 2.2.2.2 host 100.0.1.99 (hitcnt=0)

Conclusion 6:
On post-8.3 ASA, for destination NAT, NAT is checked before the ACL and before the routing.
1. UN-NAT (destination NAT)/Partial Routing (find the exit interface based on NAT configuration)
2. ACL

Packet-tracer shows:
ASA1# packet-tracer input outside icmp 2.2.2.2 8 0 100.0.1.99

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: UN-NAT
Subtype: static
...
nat (inside,outside) source static R1_REAL_1.1.1.1 R1_NAT_100.0.1.99
Additional Information:
NAT divert to egress interface inside
Untranslate 100.0.1.99/0 to 1.1.1.1/0

Phase: 3
Type: ACCESS-LIST
...
access-group OUTSIDE_IN in interface outside
access-list OUTSIDE_IN extended permit ip host 2.2.2.2 host 1.1.1.1

...

Phase: 6

https://learningnetwork.cisco.com/thread/46543 4/9
3/8/2018 ASA order of operations (pre-8.3 and post 8.3) - 46543 - The Cisco Learning Network
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (inside,outside) source static R1_REAL_1.1.1.1 R1_NAT_100.0.1.99

Note that packet-tracer doesn't show explicitly the routing checking phase since there was 'partial routing' check after the UN-
NAT

SUMMARY
pre-8.3 ASA with source NAT:
1. Routing
2. Inbound ACL
3. NAT

pre-8.3 ASA with destination NAT:

1. ACL
2. UN-NAT (destination NAT)
3. Routing

post-8.3 ASA with source NAT:

1. Routing
2. Inbound ACL
3. NAT

post-8.3 ASA with destination NAT:

1. UN-NAT (destination NAT)/Partial Routing
2. ACL

Please, feel free to correct me or to add on my testings above.

Mikis

65203 Views Tags:

MOST LIKED

MIKIS Mar 9, 2013 4:37 PM (in response to MIKIS)

1. Re: ASA order of operations (pre-8.3 and post 8.3)

I added VPN and Dual NAT in the equation. Any thoughts are welcomed

Regards

Mikis

Actions Like (4)

Daniel Kuhl CCDP, CCNP R&S / Sec. Feb 22, 2013 12:34 AM (in response to MIKIS)

2. Re: ASA order of operations (pre-8.3 and post 8.3)

Hey Mikis,

thank you for this great post. I followed your post to make sure the ASA order of operations for myself. I hope to have some
time to also test VPN and Dual-NAT operations this weekend.

regards,
Daniel

https://learningnetwork.cisco.com/thread/46543 5/9
3/8/2018 ASA order of operations (pre-8.3 and post 8.3) - 46543 - The Cisco Learning Network

Actions Like (0)

MIKIS Mar 9, 2013 4:26 PM (in response to MIKIS)

3. Re: ASA order of operations (pre-8.3 and post 8.3)

After checking the great presentation by Sasa Rasovic about the ASA architecture and doing some more tests I updated the
post. More specifically, in case of destination NAT (UN-NAT), there is 'partial routing' happening after the UN-NAT which finds
the exit interface based on the NAT configuration. That's why even if there is no route towards the destination, the packet
tracer shows 'Allow' as a result.

Kind regards

Mikis

Actions Like (0)

Hoang Tran Aug 7 2013 2:34 AM (in response to MIKIS)

4. Re: ASA order of operations (pre-8.3 and post 8.3)

Hi all, I have a question. When I do packet tracer on ASA 8.4.2 (btw, I'm using GNS3), from the output I see ASA performs
route-lookup first, then it checks ACL. Compare to order of operations of Cisco router, from what I read in CCNA Exploration
4.0, it said the router will check the ACL first before looking into the routing table. So my question is: Does ASA and Cisco
router different from the order of operations of route-lookup and ACL? Or do I misunderstand something?

Thanks for your help.

Actions Like (0)

swapneswar.panda Oct 9, 2013 8:31 AM (in response to Hoang Tran)

5. Re: ASA order of operations (pre-8.3 and post 8.3)

Hi MIKIS,

i am not fully comfortable with this behaviour and out come.

During this scenario testing dd you try to do some packet capture and did you check the Sh conn out put ?
Can you please just do the sh conn command when you are trying to do the ping and see the out put ?

What i opbserved is the trace order also differ in both the instances(without Route and with route).

Thanks
swap

Actions Like (0)

swapneswar.panda Oct 9, 2013 8:37 AM (in response to swapneswar.panda)

6. Re: ASA order of operations (pre-8.3 and post 8.3)

Please find some docs for packet process in ASA.

asa-packet-flow-00.pdf
37.3 K
No security policy violations found.
The file was last scanned 3 years ago.

Actions Like (2)

swapneswar.panda Oct 9, 2013 12:06 PM (in response to swapneswar.panda)

7. Re: ASA order of operations (pre-8.3 and post 8.3)

Please try this one..

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

Thanks
swap

https://learningnetwork.cisco.com/thread/46543 6/9
3/8/2018 ASA order of operations (pre-8.3 and post 8.3) - 46543 - The Cisco Learning Network

Actions Like (1)

Cody Lo Mar 11, 2014 8:23 AM (in response to MIKIS)

8. Re: ASA order of operations (pre-8.3 and post 8.3)

Hi,

I'm also running into a similar situation which we need to migrate a a firewall context from a box running 8.2 to 9.1, I'm
translating the NAT configuration to the 9.1 box. The command syntax for 9.1 is straight forward but after I translate the config
on the ASA9.1 box it doesn't work. Setup like this:

10.152.1.1/32(R1)192.168.1.0/24<security-level 100>(ASA)<security-level 0>192.168.10.0/24(R2)10.129.0.24/32

And the REAL destination IP 10.129.0.24/32 is statically translated to 10.204.98.1/32 for the clients on R1 to reach. R1 only
have a route for 10.204.98.0/24 pointing to the inside interface of the ASA.

ciscoasa(config)# show nat de

Manual NAT Policies (Section 1)
1 (inside) to (outside) source static 10.152.0.0_16 10.152.0.0_16 destination static 10.204.98.1_32 10.129.0.24_32
translate_hits = 3, untranslate_hits = 5
Source - Origin: 10.152.0.0/16, Translated: 10.152.0.0/16
Destination - Origin: 10.204.98.1/32, Translated: 10.129.0.24/32

=================
There is an access-list from the original 8.2 config which is currently working in a production envjornment.
access-list in-to-out line 1 extended permit ip 10.152.0.0 255.255.0.0 10.204.98.0 255.255.255.0 (hitcnt=0) 0x64de970e

However when I apply this ACL to the ingress of the inside interface this ACL will actually block the traffic which is because
the UN-NAT is happen before checking the ACL. If I either remove the ACL or explicit permitting the traffic to the real IP
10.129.0.24 on the outside interface (which the client is not connecting to) it will work.

Debugging log show that the connection is being denied with the translated address.

%ASA-4-106023: Deny tcp src inside:10.152.1.1/10000 dst outside:10.129.0.24/23 by access-group "in-to-out" [0x0, 0x0]

The packet flow doesn't make sense to me since it do the NAT before the ACL, while some other articles state that the ASA
will check the ACL before NAT.

Actions Like (0)

Jason B Mar 11 2014 8:51 AM (in response to Cody Lo)

9. Re: ASA order of operations (pre-8.3 and post 8.3)

In 8.3+, the ACL needs to reference the "Real" IP address, which would be the 10.129.0.24 address, even though the client is
not showing that as the address to which is it connecting. This is what you showed in your own testing, as well. The client is
connecting to a NAT address (the outside local address in this scenario.) In referencing inside/outside and local/global,
perhaps think of post 8.3 ACLs as applying to the inside local and to the outside global IP addresses of a NAT statement.

Actions Like (0)

Cody Lo Mar 11, 2014 10:03 PM (in response to Jason B)

10. Re: ASA order of operations (pre-8.3 and post 8.3)

Thank you for your comment. I did some search regarding to ASA8.3 upgrade and this have been mentioned, so we will need
to use the real (untranslated) IP of the destination in the ACL. Thank you.

http://www.cisco.com/c/en/us/td/docs/security/asa/asa83/upgrading/migrating.html#wp40036

Actions Like (0)

Meet Gill Apr 16, 2017 11:38 PM (in response to MIKIS)

11. Re: ASA order of operations (pre-8.3 and post 8.3)

Hi,

Will there be any difference in flow if we have an access-list on an interface in out direction?

https://learningnetwork.cisco.com/thread/46543 7/9
3/8/2018 ASA order of operations (pre-8.3 and post 8.3) - 46543 - The Cisco Learning Network
In destination NAT (8.2) the flow is ACL --> UN-NAT --> Routing. Now if we have an access list on outward interface in out
direction instead of in direction on inward interface then the flow will be same or different?

Thanks,
Harmeet

Actions Like (0)

Juergen Ilse CCNA R&S Apr 17, 2017 12:07 PM (in response to Meet Gill)

12. Re: ASA order of operations (pre-8.3 and post 8.3)

Meet Gill schrieb:

Will there be any difference in flow if we have an access-list on an interface in out direction?

In destination NAT (8.2) the flow is ACL --> UN-NAT --> Routing. Now if we have an access list on outward interface
in out direction instead of in direction on inward interface then the flow will be same or different?

There will be an additional step in processing (processing the out ACL). To allow the traffic from lower security level to higher
security level, you still need an in ACL on the ingress interface. So working with in ACLs and out ACLs makes your
configuration more complex and result in the need to change more than one ACL to allow traffic. So i would suggest to not
use out ACLs on ASA, if you have no really good reson for it ...

Actions Like (0)

Wasim Apr 30, 2017 4:49 AM (in response to MIKIS)

13. Re: ASA order of operations (pre-8.3 and post 8.3)

Hi Mikis,

You've done some really good work with this, however the ASA treats the packet as per its direction across its interfaces. It
treats a packet coming in on the inside interface going to the outside interface totally differently as compared to a packet
coming in on the outside interface leaving off of the inside interface. Check this out

http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/115904-asa-config-dmz-
00.html

Actions Like (0)

Juergen Ilse CCNA R&S Apr 30, 2017 6:00 AM (in response to Wasim)

14. Re: ASA order of operations (pre-8.3 and post 8.3)

I beg to differ. Packetforwarding in the ASA is (in my opinion) not "totally different depending on its direction". The default if
there is no ACL bound to an interface is "allow traffic from this interface to all interfaces with lower security level, deny all
traffic to interfaces with higher security level except "answer traffic to allowed traffic" (which is always allowed until it is
explicitely denied), deny all traffic to interfaces with the same security level (as far as there is no "same-security-traffic"
directive in the configuration, that allows such traffic). These default will be completely overridden, if there is an ACL bound to
that interface as in ACL. In this case, only traffic allowed by that ACL and "answer traffic to allowed
traffic" is allowed to come in from that interface (but traffic between interfaces of same security level is still denied
independently of the ACL
until there is a"same-security-traffic" directive in the configuration).
The different handling of nat depending on the security levels of ingress and egress interfaces in firmware upto 8.2 has gone
in 8.3 and newer, nat is independent of security levels since firmware 8.3. So i see no different handling of packets dependent
on its direction across the interfaces.

Actions Like (0)

1 2

Terms & Conditions Privacy Statement Cookie Policy Trademarks Languages Follow us:

https://learningnetwork.cisco.com/thread/46543 8/9
3/8/2018 ASA order of operations (pre-8.3 and post 8.3) - 46543 - The Cisco Learning Network

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