cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2544
Views
10
Helpful
5
Replies

ASA 5510 ignoring configured acl entry?

pheller10
Level 1
Level 1

Greetings,

  I'm configuring up aa ASA-5510, and I have several interfaces, some of which include:

interface Ethernet0/0.200

vlan 200

nameif SITECORP

security-level 90

ip address 10.1.4.1 255.255.254.0

!

interface Ethernet0/0.207

vlan 207    

nameif SITESERVER

security-level 90

ip address 10.1.7.1 255.255.255.128

!

interface Ethernet0/1.311

vlan 311

nameif MOD1BMS

security-level 100

ip address 10.1.144.1 255.255.252.0

!

I have the following access-lists configured and applied:

access-list SITECORP_access_in extended permit ip any any

access-list SITESERVER_access_out extended permit tcp object-group SITECORP object-group SITESERVER eq www

access-list MOD1BMS_out extended permit tcp object-group SITECORP object-group MOD1BMS eq www

fw# show run object-group

object-group network SITECORP

network-object 10.1.4.0 255.255.254.0

object-group network MOD1BMS

network-object 10.1.144.0 255.255.252.0

object-group network SITESERVER

network-object 10.1.7.0 255.255.255.128

fw# show run nat-control

no nat-control

packet-tracer shows traffic from SITECORP to MOD1BMS (a higher security-level) on tcp/80 is successful, whereas it shows the same traffic from SITECORP to SITESERVER is denied, due to implicit rule.

fw# packet-tracer input SITECORP tcp 10.1.4.11 1234 10.1.144.200 80 detailed

<snip>

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group SITECORP_access_in in interface SITECORP

access-list SITECORP_access_in extended permit ip any any

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xd5641ec8, priority=12, domain=permit, deny=false

        hits=1860, user_data=0xd5526cb0, cs_id=0x0, flags=0x0, protocol=0

        src ip=0.0.0.0, mask=0.0.0.0, port=0

        dst ip=0.0.0.0, mask=0.0.0.0, port=0

fw# packet-tracer input SITECORP tcp 10.1.4.11 1234 10.1.7.11 80 detailed

<snip>

Phase: 3

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xd544e8c8, priority=110, domain=permit, deny=true

hits=8, user_data=0x0, cs_id=0x0, flags=0x3000, protocol=0

src ip=0.0.0.0, mask=0.0.0.0, port=0

dst ip=0.0.0.0, mask=0.0.0.0, port=0

This definitely confuses me, because SITECORP has an inbound access-list of permit ip any any.

Can anyone suggest what I'm missing, how to go about making this work, or what more I might provide to troubleshoot?

Regards,

  Phil

2 Accepted Solutions

Accepted Solutions

Julio Carvajal
VIP Alumni
VIP Alumni

Hello Phil,

Hope you are doing fine.

As you can see both zones have the same security level, by default the ASA will not allow that traffic ( same security level traffic).

This command will solve your problem.

     -same-security-traffic permit inter-interface

Please rate helpful posts.

Kind regards,

Julio

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

View solution in original post

Hello Phil,

That is correct no matter what ACE (access-list entries) you have configured on one interface, if that interface wants to talk to another one with the same security level, the connection would not be allowed (Asa/Pix speaking)

But you do not have to change the Security level, of course that is one work-around but again the solution is :

-     same-security-traffic permit inter-interface

Please mark the question as answered for future queries regarding the same issue unless you have any other question, I would be more than glad to help.

Regards,

Julio

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

View solution in original post

5 Replies 5

Julio Carvajal
VIP Alumni
VIP Alumni

Hello Phil,

Hope you are doing fine.

As you can see both zones have the same security level, by default the ASA will not allow that traffic ( same security level traffic).

This command will solve your problem.

     -same-security-traffic permit inter-interface

Please rate helpful posts.

Kind regards,

Julio

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

Julio,

  Thanks for the reply.

  So traffic between interfaces with the same security-level is not treated the same as traffic to an interface with a higher security-level?  I.e., an access-policy permitting the traffic will be insufficient?

In any case, thanks, simply revisiting the interface security-level configurations did allow me to resolve this problem.

Regards,

  Phil

Hello Phil,

That is correct no matter what ACE (access-list entries) you have configured on one interface, if that interface wants to talk to another one with the same security level, the connection would not be allowed (Asa/Pix speaking)

But you do not have to change the Security level, of course that is one work-around but again the solution is :

-     same-security-traffic permit inter-interface

Please mark the question as answered for future queries regarding the same issue unless you have any other question, I would be more than glad to help.

Regards,

Julio

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

Thanks, Julio.

I did implement the same-security-traffic permit inter-interface, and it absolutely worked.  The ASA has a dozen other vlan interfaces, and it made sense to re-visit the security-level.

You've certainly thoroughly answered the question, and I fully understand now.

Thanks!

--phil

Hello Phil,

I am glad to hear that, any other question just let me know.

Kind regards,

Julio

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC
Review Cisco Networking for a $25 gift card