cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4325
Views
5
Helpful
4
Replies

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

mz331wcisco
Level 1
Level 1

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

4 Replies 4

Julio Carvajal
VIP Alumni
VIP Alumni

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

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

mz331wcisco
Level 1
Level 1

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

Hello Mikis,

Great information,

Where did you see that presentation?

Regards,

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

I think Mikis is talking about this ciscolive session:

https://ciscolive365.com/connect/sessionDetail.ww?SESSION_ID=6037&backBtn=true

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: