topic Re: Direction of ACL traffic flow in Network Security

Direction of ACL traffic flow

mahesh18 — Tue, 12 Mar 2019 02:32:46 GMT

Hi Everyone,

Need to confirm below that log

%ASA-6-106100: access-list Test_access_in denied tcp Test/172.24.x.x(443) -> Test/172.16.x.x(53310) hit-cnt 1 first hit [0x55b05541, 0x7c3c1e84]

Does this mean that traffic from interface Test on port 443 to interface Test1 of ASA is denied as there is no acl to allow trafic from 172.24 to 172.16?

or is this other way around?

Regards

Mahesh

Direction of ACL traffic flow

Jouni Forss — Fri, 30 Aug 2013 18:02:27 GMT

Hi Mahesh,

Seems to me that its not the typical Deny message related to ACLs. It might be that you have some ACL configuration with the "log" parameter configured at the end.

It still doesnt explain why this was Denied.

It seems to me to be return traffic for some HTTPS connection but I am not sure why the firewall would block it. Unless we are possinly talking about Asymmetric Routing where the firewall blocks the a return packet for some connection that the ASA in question hasnt seen.

Here is a link to the above mentioned Syslog ID 106100 information/explanation:

http://www.cisco.com/en/US/docs/security/asa/syslog-guide/logmsgs.html#wp4769049

- Jouni

Re: Direction of ACL traffic flow

mahesh18 — Fri, 30 Aug 2013 18:21:38 GMT

Hi Jouni,

You are absolutely correct that log was created due to asymmetric routing issue.

I fixed the routing issue and all is well now.

But for my understanding need to learn what does log mean here.

Traffic to destination was going via interface Test1 and when return traffic comes back to this firewall it was coming on

interface Test.

After routing issue fixed return traffic was coming back on interface Test1.

so now if we look at log again

%ASA-6-106100: access-list Test_access_in denied tcp Test1/172.24.x.x(443) -> Test/172.16.x.x(53310) hit-cnt 1 first hit [0x55b05541, 0x7c3c1e84]

Can we conclude that traffic is coming on interface Test and is trying to go to interface Test1 of the same ASA?

Source is 172.16 and destination is 172.24?

It did not allow traffic from interface Test to Test1 because there is no ACL to allow traffic from interface Test to Test1?

Regards

Mahesh

Message was edited by: mahesh parmar

Direction of ACL traffic flow

Jouni Forss — Fri, 30 Aug 2013 19:39:40 GMT

Hi,

I am not quite sure about the situation. It seems to me that the initial connection would have come from Test to Test1 looking at the ports.

It would probably best to see the "packet-tracer" output for this same connection

packet-tracer input Test tco 172.16.x.x 12345 172.24.x.x 443

Perhaps also the output of

show run access-group

- Jouni

Re: Direction of ACL traffic flow

mahesh18 — Fri, 30 Aug 2013 19:50:03 GMT

Hi Jouni,

Packettracer does not work.

Return traffic comes from interface Test to Test1.

access-group Test_access_in in interface Test1

access-group Test in interface Test

Regards

Mahesh

Re: Direction of ACL traffic flow

Harvey Ortiz — Sat, 31 Aug 2013 04:47:58 GMT

Hi Mahesh,

Please provide the packet-tracer

packet-tracer input Test tcp 172.16.x.x 12345 172.24.x.x 443

Regards,

Harvey

Direction of ACL traffic flow

Jouni Forss — Sat, 31 Aug 2013 05:07:36 GMT

Hi Mahesh,

The "packet-tracer" should work. Just make sure you insert the actual IP addresses to the command instead of the ones with the "x.x" since you didnt mention the full IP addresses in your posts

- Jouni

Re: Direction of ACL traffic flow

mahesh18 — Fri, 06 Sep 2013 19:59:02 GMT

Hi Jouni,

I found this from ASA -syslog message pdf

Error Message %ASA-4-106100: access-list acl_ID {permitted | denied | est-allowed}

protocol interface_name/source_address(source_port) (idfw_user, sg_info)

interface_name/dest_address(dest_port) (idfw_user, sg_info) hit-cnt number

({first hit | number-second interval}) hash codes

So as per this the source is Test1 interface and going to Destination interface Test.The reason it was denied due to Asymmetric route.

Also from Cisco site

For

example, if an ACK packet is received on the ASA (for which no TCP connection exists in the

connection table), the ASA might generate message 106100, indicating that the packet was

permitted; however, the packet is later correctly dropped because of no matching connection.

so due to above reason the packet was dropped.

Best regards

Mahesh