09-02-2012 07:23 AM - edited 03-11-2019 04:48 PM
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
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
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
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:
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
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
09-02-2012 11:42 AM
Hello Mikis,
Fair enough, Just remember beggining on 8.3 how the ASA handles the packets it's different from 8.2 and older versions.
As you said now the ASA is going to check the proper Nat rules first and then the Acl's that is why when we want to allow traffic from outside to an inside server we need to poing the ACL to the private or un-nated Ip as the nat rule was taken in place first
Good post by the way,
Remember to rate all the community answers, for us that is more important than a thanks
Julio
03-09-2013 04:29 PM
After checking the great presentation by Sasa Rasovice 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'.
Kind regards
Mikis
03-09-2013 08:23 PM
Hello Mikis,
Great information,
Where did you see that presentation?
Regards,
03-10-2013 03:35 AM
I think Mikis is talking about this ciscolive session:
https://ciscolive365.com/connect/sessionDetail.ww?SESSION_ID=6037&backBtn=true
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide