ASA 5520 Flow is Denied by Configured Rule

[jeremyn]

Hello all,

New to the forums and the Cisco ASA 5520. 

I am attempting to allow traffic from one vlan to another.

• Vlan 1 is on Interface 0/2.vlan1
• Vlan 2 is on int 0/3.vlan2
• Each vlan can communicate inside it's own vlan, and the gateway on each responds to vlan specific clients

My problem is that I am unable to communicate between the two vlans.  Using the ASDM packet tracer tool, I find that packets are denied by the default rule (on the second Access List lookup).  It appears as if the packet never reaches the other interface.  Any help is appreciated.  The access rules are set up to allow traffic from one vlan to another (inbound), on both interfaces.  Testing from either vlan to connect to the other fails.  Below are the accee-rules for each vlans.  Once I get basic connectivity working, I hope to clean it up.

access-list aVlan1; 3 elements; name hash: 0xadecbc34

access-list aVlan1 line 1 extended permit ip any 192.168.151.64 255.255.255.192 (hitcnt=0) 0xeb0a6bb8

access-list aVlan1 line 2 extended permit ip any 192.168.151.128 255.255.255.128 (hitcnt=0) 0x3a7dfade

access-list aVlan1 line 3 extended permit ip any 192.168.151.0 255.255.255.0 (hitcnt=0) 0x93302455

access-list aVlan2_access_in; 3 elements; name hash: 0x6dc9adc7

access-list aVlan2_access_in line 1 extended permit ip 192.168.151.64 255.255.255.192 192.168.150.0 255.255.255.240 (hitcnt=0) 0x054508b7

access-list aVlan2_access_in line 2 extended permit ip 192.168.151.128 255.255.255.128 192.168.150.0 255.255.255.240 (hitcnt=0) 0xc125c41e

access-list aVlan2_access_in line 3 extended permit ip host 192.168.151.3 192.168.150.0 255.255.255.240 (hitcnt=0) 0x4adc114c

Thanks,

J

[Eddy Duran]

Hello Jeremy,

What is the security level for those interfaces?

Try to add this command:

same-security-traffic permit inter-interface

I would like you to post the packet tracer if possible.

-Eddy Duran

[jeremyn]

Hi Eddy,

Thanks for your response.  Each subinterface has a security level of 30.  I need a day or so to determine if there will be any adverse effects of applying that rule.

Packet tracer and applicable rules below.  

Thanks for the help,

J

[Jouni Forss]

Hi,

Having each local firewall interface on the same "security-level" at the moment means that they have no chance of communicating with eachother (even with ACLs configured) unless the above mentioned configuration command is inserted.

If you were to insert the command the following things might happened depending on your configurations

• An interface which has no ACL attached would be able to initiate connections towards any of the other interfaces with the equal "security-level" value.
• An interface which has an ACL attached would be matched against its ACL rules and those would determine to which networks or hosts behind the other local interfaces the hosts behind this interface could connect to.

Generally if I would want to configure a setup where I have multiple local interfaces on the ASA and would want to rule out any traffic between them I would always use ACLs on each interface instead of using "security-level" value.

The way I would do it would be to

• Create an "object-group network" which contains ALL the local networks
• Create an ACL for each interface which starts with a "deny ip any object-group " which would by default block all traffic from the behind that interface to ANY other network behind the ASAs local interfaces
• Create a permitting statement for the local networks behind that interface to "any" destination address which would essentially enable Internet bound traffic (as we have blocked all local networks before)

If I would have to need to enable some traffic between local networks behind different interfaces I would simply add "permit" statements at the TOP of the needed ACLs with a "remark" describing what traffic is allowed. The existing "deny" statement would still make sure that no other traffic between the local networks would be allowed unless I specifically allowed it in the top of the interface ACL.

Hope this helps

- Jouni

[jeremyn]

This does help, thanks Jouni,

Ideally, I would like to implement what you suggest but I think it would take some careful planning.  In the mean time, I'd like to enable access between the two subinterfaces.  Would changing the security level of the subinterface where traffic would be intiated from to a higher security level solve this problem?  Alternatively I could drop the security level of the other subinterface.

Thanks,

J

[Jouni Forss]

Hi,

Increasing the "security-level" of the source interface might be the best choice at this point. (As I have no knowledge of the rest of the setup)

As you already have the ACL configured on the source interface, then increasing the "security-level" value of the interface wouldnt really change what traffic is allowed and what is not since the ACL will specify that. Changing the "security-level" would however get around the immidiate problem you are facing now which is that networks behind equal "security-level" interfaces cant communicate.

If you were to lower the "security-level" of the destination interface it might change the whole setup more. And I can only guess but to me it would seem that if you have several other local interfaces with value 30 without ACL and this destination was now changed to 29 for example then some traffic might start get allowed that you dont wish to be allowed

If one of the reply is the correct answer to your question, please do mark it as the correct answer. Also if you have found some information helpfull, please take the time to rate these replys

Naturally ask more and I will try to help out.

- Jouni

[jeremyn]

Thanks Jouni,

I will test this today and either mark as answered or follow up.

Cheers,

J

[jeremyn]

Hi I changed the security level of the first interface higher and tested an ip packet from that subnet to the other (40/30).  It failed, citing the same default rule.  It appears to be blocked at that interface and never reaches the other interface.  Any other ideas?

Thanks,

J

[Jouni Forss]

Hi,

I am not sure what exactly you are testing. I imagine its certain destination IP and TCP/UDP ports connection.

Could you perhaps try this

Go to

• ASDM
• Tools -menu
• Command Line Interface
• Insert the following command (while filling the information to match your connection test)

packet-tracer input

Where

• nameif = Is the name of the interface where the source host for this connection test is located at. In other words the name of the interface from where the packet is "input"
• protocol = TCP or UDP
• source ip = Is the hosts IP address that is initiating the connection
• source port = Is the random source port for the connection attempt
• destination ip = Is the destination IP address
• destination port = Is the port on the destination host you are trying to reach

You can use the Send button to send the command to the ASA and it will print out the CLI format of the Packet Tracer output. You can then copy/paste it here (minus any possible public IP address information incase something shows)

- Jouni

[Jouni Forss]

Also,

Just to check, you have attached the ACLs to the interfaces right?

If not then the output you are seeing might be possible also.

You can use the command "show run access-group" to view the ACL attached to the interfaces

- Jouni

[jeremyn]

Sorry, no luck:

packet-tracer input wta2COB icmp 192.168.150.1 0 0 192.168.151.3

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

Phase: 3

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   192.168.151.0   255.255.255.0   FACSURV

Phase: 4

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Result:

input-interface: WTA2COB

input-status: up

input-line-status: up

output-interface: FACSURV

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

access-group aWTA2COB in interface WTA2COB

access-group FACSURV_access_in in interface FACSURV

Thanks for the continued responses.

[Eddy Duran]

Jeremy,

Thanks for the update.

Can you post the show access-list command from the unit? If possible a show run from the unit?

-Eddy Duran

[Jouni Forss]

Hi,

The "packet-tracer" code is incorrect

You are testing ICMP with it and basicly inserting a ICMP Echp reply (Type 0 Code 0)

You need to use this

packet-tracer input wta2COB icmp 192.168.150.1 8 0 192.168.151.3

Which is ICMP Echp (Type 8 Code 0)

- Jouni

[jeremyn]

Thanks all,

I worked on this some more today, testing with some additional rules.  The ASA is acting like it doesn't see my rules:

Added NAT statements:

nat (FACSURV) 0 access-list NoNAT

nat (FACSURV) 1 0.0.0.0 0.0.0.0

nat (WTA2COB) 0 access-list NoNAT

nat (WTA2COB) 1 0.0.0.0 0.0.0.0

Access rules below:

access-list aWTA2COB; 5 elements; name hash: 0xadecbc34

access-list aWTA2COB line 1 extended permit ip any 192.168.151.64 255.255.255.192 (hitcnt=0) 0xeb0a6bb8

access-list aWTA2COB line 2 extended permit ip any 192.168.151.128 255.255.255.128 (hitcnt=0) 0x3a7dfade

access-list aWTA2COB line 3 extended permit ip any 192.168.151.0 255.255.255.0 (hitcnt=0) 0x93302455

access-list aWTA2COB line 4 remark test

access-list aWTA2COB line 5 extended permit ip any any (hitcnt=0) 0xdbfec94c

access-list aWTA2COB line 6 remark test

access-list aWTA2COB line 7 extended permit icmp any any (hitcnt=0) 0x2cece62d

access-list FACSURV_access_in; 5 elements; name hash: 0x6dc9adc7

access-list FACSURV_access_in line 1 extended permit ip 192.168.151.64 255.255.255.192 192.168.150.0 255.255.255.240 (hitcnt=0) 0x054508b7

access-list FACSURV_access_in line 2 extended permit ip 192.168.151.128 255.255.255.128 192.168.150.0 255.255.255.240 (hitcnt=0) 0xc125c41e

access-list FACSURV_access_in line 3 extended permit ip host 192.168.151.3 192.168.150.0 255.255.255.240 (hitcnt=0) 0x4adc114c

access-list FACSURV_access_in line 4 extended permit ip any any (hitcnt=9) 0x9fedc480

access-list FACSURV_access_in line 5 remark test

access-list FACSURV_access_in line 6 extended permit icmp any any (hitcnt=0) 0xd74c33b6

Packet Tracer result:

packet-tracer input wta2COB icmp 192.168.150.1 8 0 192.168.151.3

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

Phase: 3

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   192.168.151.0   255.255.255.0   FACSURV

Phase: 4

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Result:

input-interface: WTA2COB

input-status: up

input-line-status: up

output-interface: FACSURV

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

I will open a TAC case today.  If you have any further input, I'm willing to test. 

Thanks,

J

[Jouni Forss]

Hi,

Would you be willing to share the complete configuration?

If you want you can share it through a PM (private message) on the forums. (That is if you dont want to share it in this post I mean)

This would give a chance to go through the problem better.

- Jouni