ACL Clarification

I know I'm a CCNA and I should have known better

, but I need a refresher. Is it true that regardless of which interface we implement the extended ACL rule on, we would always follow the INBOUND --> ROUTING PROCESS --> OUTBOUND logic?

What I am trying to understand is why the host from the 192.168.0.0/24 network were able to get the echo replies from pinging the R1's F0/0 interface when I applied the following access-list rule:

interface FastEthernet0/0
ip address 192.168.0.254 255.255.255.0
ip access-group 100 out

access-list 100 deny icmp any any

I was able to ping both R1 interfaces (which I did not expect), but when I tried to ping, R2's s1/0 interface, I get the "request timed out" message, which I was expecting. I am trying to understand the ACL logic here, because I can't wrap that around my head yet when I was clearly denying all ICMP traffic coming out of that interface. Even if I didn't, the implicit deny rules should deny it anyway. Earlier, I was trying to stop the EIGRP HELLO messages from advertising out the F0/0 interface using ACLs, but it couldn't be done. Only the passive-interface command was able to do that. I wonder if the same logic applies here.

check.jpg

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

drkat

The acl on Fa0/0 only blocks it egress - inside hosts originating pings would be blocked - the traffic inbound to fa0/0 (ingress) is considered OK

If you wanted to block icmp I'd do it on R1's WAN interface - as the router doesnt have to then process icmp and then drop it.

hiddenknight821

I can block ICMP messages originating from the LAN by just using the "ip access-group 100 in" instead. It was my intention to expect the IMCP echo request to go through R1's f0/0, but I didn't think the ICMP echo reply would go back out on the same interface since I thought it would be blocked after the router process it (but I don't believe it does for its connected interfaces but that's what I would like to know). I am not concerned with ICMP pings originating from R1 WAN side as I was only conducting experiment to test my hypothesis.

m3zilla

Your ACL is applied on the outbound direction of FA0/0. This means that incoming ICMP is allowed, and the reason why echo replies are received is because ACL do no apply to traffic originated from the router.

georgemc

hiddenknight821 wrote: »

I can block ICMP messages originating from the LAN by just using the "ip access-group 100 in" instead. It was my intention to expect the IMCP echo request to go through R1's f0/0, but I didn't think the ICMP echo reply would go back out on the same interface since I thought it would be blocked after the router process it (but I don't believe it does for its connected interfaces but that's what I would like to know). I am not concerned with ICMP pings originating from R1 WAN side as I was only conducting experiment to test my hypothesis.

What affect do ACLs have on packets originated from the router itself?

If you answer that question, then you'll have the answer to your question.

hiddenknight821

@georgemc: You are right about that! That's the straightforward question I should have asked in the first place!

I didn't perceive it as "traffic originating from the router" since the echo request provoked that traffic, but I see where I was wrong.

Thanks guys for clearing this up!