ACL Clarification
hiddenknight821
Member Posts: 1,209 ■■■■■■□□□□
in CCNA & CCENT
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.
Comments
-
drkat Banned Posts: 703The 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 Member Posts: 1,209 ■■■■■■□□□□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 Member Posts: 172Your 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 Member Posts: 429hiddenknight821 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.WGU BS: Business - Information Technology Management
Start Date: 01 October 2012
QFT1,PFIT in progress.
TRANSFERRED/COMPLETED: AGC1,BBC1,LAE1,QBT1,LUT1,QLC1,QMC1,QLT1,IWC1,INC1,INT1,BVC1,CLC1,MGC1, CWV1 BNC1, LIT1,LWC1,QAT1,WFV1,EST1,EGC1,EGT1,IWT1,MKC1,MKT1,RWT1,FNT1,FNC1, BDC1,TPV1 REQUIRED: -
hiddenknight821 Member Posts: 1,209 ■■■■■■□□□□@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!