Cisco – ACL Clarification

aclcisco

I have a question about Cisco ACL's.

If a router has an ACL which denies pings and replies, which is stopping any devices on the LAN from pinging the internet but the router can still ping the internet, why is this the case?

Is this because the router isn't affected by ACL's whereas the PC's are?

Thanks

Best Answer

I don't mean for this to be considered an answer, I just wanted to show the output of testing @OzNetNerd's answer.

I configured three routers:

R1 ----- R2 ----- R3

Gave them each an IP and a Loopback interface. Configured an ACL to block ICMP traffic:

R2#show ip access-lists
Extended IP access list DENY-ICMP
    10 deny icmp any any
    20 permit ip any any

And applied it direction OUT on the interface facing R3:

R2#show ip interface | i line|Internet|list
FastEthernet0/0 is up, line protocol is up
  Internet address is 10.1.2.2/24
  Outgoing access list is not set
  Inbound  access list is not set
FastEthernet0/1 is up, line protocol is up
  Internet address is 10.2.3.2/24
  Outgoing access list is DENY-ICMP
  Inbound  access list is not set
Loopback0 is up, line protocol is up
  Internet address is 2.2.2.2/32
  Outgoing access list is not set
  Inbound  access list is not set

I than ran three tests, pinging 3.3.3.3 from R2 natively, then source from interface L0, then sourced from interface fa0/0. All three were successful:

R2#ping 3.3.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/69/92 ms
R2#ping 3.3.3.3 source l0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/80/104 ms
R2#ping 3.3.3.3 source fa0/0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 10.1.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/30/52 ms

All the while the ACL hitcount stayed at 0 (even the permit):

R2#show ip access-list
Extended IP access list DENY-ICMP
    10 deny icmp any any
    20 permit ip any any

And all the while R1 was unable to ping R3:

R1#ping 3.3.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
UUUUU
Success rate is 0 percent (0/5)

R1's attempt did increase the ACL Hitcount:

R2#show ip access-list
Extended IP access list DENY-ICMP
    10 deny icmp any any (15 matches)
    20 permit ip any any
R2#

(although why it did so by 15 when only 5 attempts were sent is curious, anyone have any ideas?)

I did the same test sourcing the ping from the IP 2.2.2.2 and 10.1.2.2 (the addresses on R2's L0 interface and the interface facing R1), and the results were the same. All this was on GNS3 running 12.4:

R2#show ver | i Ver
Cisco IOS Software, 3700 Software (C3725-ADVENTERPRISEK9-M), Version 12.4(25), RELEASE SOFTWARE (fc2)
ROM: 3700 Software (C3725-ADVENTERPRISEK9-M), Version 12.4(25), RELEASE SOFTWARE (fc2)

My testing confirms, @OzNetNerd is correct, ACLs do not apply to traffic sourced from the router itself.

I did test applying an INbound ACL on R2's f0/1 (interface facing R3). And that did successfully block the return ICMP Responses from R3. But the initial ICMP Echo's did indeed make it out and to R3 (as expected). I confirmed this with debugs on R3.

Related Topic