0

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

Improve this question
4
  • 1
    The router is affected also, depending on how the ACL is written. Can you post it? – Ron Trunk Nov 19 '15 at 13:34
  • 1
    You probably have the ACL as inbound one on the LAN interface, preventing only devices on that segment from pinging into (or through) the router, but not preventing the router itself from egressing ICMP out any interfaces. – stevieb Nov 19 '15 at 15:08
  • 1
    No offence intended, but the above comments are incorrect. An ACL on a router does not affect traffic originated by that same router. See my post below for more information. – OzNetNerd Nov 20 '15 at 2:18
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide your own answer and accept it. – Ron Maupin♦ Aug 7 '17 at 14:52
4

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.

Improve this answer
1
  • 3
    Hehe, I didn't get a chance to lab mine up again until just a bit ago and looks like you posted while I was typing mine up. Never hurts to have more than one answer though. – YLearn♦ Nov 21 '15 at 2:44
3

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

Yes, this is correct. The router's ACLs do not affect traffic which is originated by the router itself (e.g the router pinging an internet address). This is true regardless of whether the ACLs are placed inbound, outbound, on an SVI, physical interface, etc.

If you want to filter traffic which is originated by the router, you need to use the "ip local policy route-map" command.

EDIT: Adding references as per YLearn's suggestion:

  • Cisco forum - Suggestion is to use "ip local policy route-map" to block traffic originating from the router.
  • Cisco documentation - "Access lists that are applied to interfaces do not filter traffic that originates from that router."
  • Cisco forum - Information on how the router's ACLs do not apply to traffic originating from the router.
Improve this answer
9
  • 1
    This is not completely accurate. If you have an outbound ACL on a router interface, and you source traffic from a different router interface through the interface on which the ACL is configured, the ACL can absolutely affect the traffic. The reality is that if the traffic passes, in the proper direction, through an ACL the ACL can affect the traffic. You are confused by the fact that traffic sourced on the interface where the ACL is is not affected by the ACL. – Ron Maupin♦ Nov 20 '15 at 5:59
  • You can test this by creating a loopback interface, put an outbound ACL on a LAN interface which blocks ICMP, ping something on the LAN with the source of the ping as the loopback interface, and the pings from the router will be blocked.. – Ron Maupin♦ Nov 20 '15 at 6:04
  • @RonMaupin, I have to disagree with you on this one. All the Cisco docs I have ever read side with Oz on this one and when I test this in my lab, my results match the Cisco docs no matter which interface I use as a source. "An access list can control traffic arriving at a device or leaving a device, but not traffic originating at a device". I can pull you other references as well. – YLearn♦ Nov 20 '15 at 6:55
  • @YLearn, I just tried it on a router here before I posted. I can ping a host on the LAN, but when I source the ping from any other interface, the ACL blocks it. – Ron Maupin♦ Nov 20 '15 at 7:02
  • @RonMaupin that's interesting. Did you see the ACL hit count increment? And are you able to obtain any debug outputs which confirm it is the ACL which is responsible for dropping the traffic? YLearn, thanks for the suggestion, I have added a few references. – OzNetNerd Nov 20 '15 at 12:17
3

According to Cisco documentation that I have found, traffic sourced by a router is not affected by access list on the router's interfaces, only on traffic that transits the router.

Here are some quotes from Cisco documentation linked to their respective documents:

Now, there do appear to be exceptions to these statements. Ron has been able to show that the ACL does have an effect, at least in some cases. I haven't found any documentation to back this up, but perhaps a device with L2 functionality such as the ISR that he used behaves differently? I sometimes can get access to a non-production 7600 so if I get a chance to test with that I will update with my findings.

Here are the results I can get consistently across the routers in my lab (1800s, 2500s, 2600/2600XMs, and 3825) across a variety of codes. I will also note that I did cut some lines at points to reduce the length of the output (some of my extra play/testing, interface output not relevant to this test, etc). To start, let's establish some basic information by showing the serial interface on this router, the loopback on this router, the cdp neighbor showing the neighbor router, routing to the loopback on the neighbor router (which includes IP from serial on that side) and a basic ping to set the baseline:

r7#sh ip int brie
Interface                  IP-Address      OK? Method Status                Protocol
Serial0/0                  10.78.1.1       YES NVRAM  up                    up    
Loopback0                  10.7.1.1        YES NVRAM  up                    up    
r7#sh cdp nei
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
r8               Ser 0/0            134          R        2610      Ser 0/0
r7#sh ip route 10.8.1.1
Routing entry for 10.8.1.1/32
  Last update from 10.78.1.2 on Serial0/0, 6w4d ago
  Routing Descriptor Blocks:
  * 10.78.1.2, from 10.78.1.2, 6w4d ago, via Serial0/0
r7#ping 10.78.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.78.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

So, let's start the fun:

r7#sh ip access-lists
Extended IP access list TestACL
    deny icmp any any echo
    deny icmp any any echo-reply
    permit ip any any
r7#config t
r7(config)#int Ser 0/0
r7(config-if)#ip access-group TestACL out
r7(config-if)#end
r7#ping 10.78.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.78.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
r7#ping 10.8.1.1 source lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.8.1.1, timeout is 2 seconds:
Packet sent with a source address of 10.7.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
r7#ping 10.78.1.2 source lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.78.1.2, timeout is 2 seconds:
Packet sent with a source address of 10.7.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
r7#sh ip access-lists
Extended IP access list TestACL
    deny icmp any any echo
    deny icmp any any echo-reply
    permit ip any any

So, I show my access list, apply it to the serial interface, and run the same ping, then ping both remote IP addresses sourced from loopback. All three work just fine and showing the access list again, note there are no hits. But maybe I applied it backwards?

r7(config)#int Ser 0/0
r7(config-if)#no ip access-group out
r7(config-if)#ip access-group TestACL in
r7(config-if)#end
r7#ping 10.78.1.2

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

Now it looks like it was blocked, but not because I applied it backwards. Let's look at the access list again:

r7#sh ip access-lists
Extended IP access list TestACL
    deny icmp any any echo
    deny icmp any any echo-reply (10 matches)
    permit ip any any (17 matches)

We can see based on the counters that it is the echo-reply from the neighbor router that is being blocked when coming into the interface. This is what we should expect using this ACL inbound. Note that the permit statement now also has matches. These are the routing updates and other traffic from the neighboring router, but note above that the outbound ACL didn't get any permit matches even the local router is also participating in routing.

Observant readers may point out that my ACL doesn't match Ron's. It is actually based on the original question posted by the OP. But let's run a test similar to Ron's to rule that out as well. I also went ahead and explicitly allowed my second IP just to have the match counter if it applied.

r7#config t
r7(config)#int ser 0/0
r7(config-if)#no ip access-group in
r7(config-if)#exit
r7(config)#no ip access-list extended TestACL
r7(config)#ip access-list extended TestACL
r7(config-ext-nacl)#permit icmp any host 10.8.1.1
r7(config-ext-nacl)#deny icmp any host 10.78.1.2
r7(config-ext-nacl)#permit ip any any
r7(config-ext-nacl)#end
r7(config)#int ser 0/0
r7(config-if)#ip access
r7(config-if)#ip access-group TestACL out
r7(config-if)#end
r7#sh ip access-lists TestACL
Extended IP access list TestACL
    permit icmp any host 10.8.1.1
    deny icmp any host 10.78.1.2
    permit ip any any
r7#ping 10.8.1.1 sourc lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.8.1.1, timeout is 2 seconds:
Packet sent with a source address of 10.7.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
r7#ping 10.78.1.2 source lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.78.1.2, timeout is 2 seconds:
Packet sent with a source address of 10.7.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
r7#sh ip access-lists
Extended IP access list TestACL
    permit icmp any host 10.8.1.1
    deny icmp any host 10.78.1.2
    permit ip any any
Improve this answer
3
  • 1
    I can certainly appreciate all the thorough testing that you and @Eddie have done. I didn't think to study it in any sort of depth, I was just doing a quick and dirty test to see what happens, and what I put in my answer was the full extent of my testing. I will see if I can do some better tests in a few weeks. I'm willing to concede that there could be something else in the rest of the configurations already in place on the router I tested which affected my test. I will withdraw my answer until I can do more confirmation. – Ron Maupin♦ Nov 21 '15 at 3:00
  • 2
    Nah, keep your answer. It begs the question of there being exceptions to the rules. If anything, just edit it to add what you put in the comment. Besides, part of my answer makes no sense if you remove yours. – YLearn♦ Nov 21 '15 at 3:01
  • 2
    OK, done. This has me very curious, and I will see if I can find an engineer who has something on the bench when I go back to work. It's sort of the wrong time of the year for that (big rush to do stuff before we have to freeze for the year end). – Ron Maupin♦ Nov 21 '15 at 3:07
1

It really depends on which side of the ACL from which the ping is originated. If you have an inbound ACL on the LAN ports, pings originating on the LAN won't even enter the router, but the pings from the router are already in the router so they never cross or are evaluated by the ACL.

There are standard and extended ACLs, and ACLs are applied to interfaces in one direction (either inbound or outbound). The ACL does nothing unless traffic crosses it in the correct direction, then the traffic is evaluated against the ACL, and the traffic is either permitted or denied based on the ACL rules.

Test:

Router1(config)#ip access-list extended Test   
Router1(config-ext-nacl)#deny icmp any host 203.0.113.8
Router1(config-ext-nacl)#permit ip any any
Router1(config-ext-nacl)#int vlan100
Router1(config-if)#ip access-group Test out
Router1(config-if)#do ping 203.0.113.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 203.0.113.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
Router1(config-if)#do ping 203.0.113.7
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 203.0.113.7, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
Router1(config-if)#do ping 203.0.113.8 source loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 203.0.113.8, timeout is 2 seconds:
Packet sent with a source address of 192.0.0.8 
.....
Success rate is 0 percent (0/5)
Router1(config-if)#do ping 203.0.113.7 source loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 203.0.113.7, timeout is 2 seconds:
Packet sent with a source address of 192.0.0.8 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
Router1(config-if)#do ping 203.0.113.8 source vlan 101  
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 203.0.113.8, timeout is 2 seconds:
Packet sent with a source address of 203.0.113.129 
.....
Success rate is 0 percent (0/5)
Router1(config-if)#do ping 203.0.113.7 source vlan 101
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 203.0.113.7, timeout is 2 seconds:
Packet sent with a source address of 203.0.113.129 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
Router1(config-if)#do ping 203.0.113.8 source vlan 102
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 203.0.113.8, timeout is 2 seconds:
Packet sent with a source address of 192.0.2.253 
.....
Success rate is 0 percent (0/5)
Router1(config-if)#do ping 203.0.113.7 source vlan 102
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 203.0.113.7, timeout is 2 seconds:
Packet sent with a source address of 192.0.2.253 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
Router1(config-if)#

EDIT:

I can certainly appreciate all the thorough testing that @YLearn and @Eddie have done. I didn't think to study it in any sort of depth, I was just doing a quick and dirty test to see what happens, and what I have above is the full extent of my testing. I will see if I can do some better tests in a few weeks. I'm willing to concede that there could be something else in the rest of the configurations already in place on the router I tested which affected my test.

Improve this answer
7
  • Which platform was this done on? – YLearn♦ Nov 20 '15 at 18:00
  • It was an ISR G2 with a 24-port switch module. – Ron Maupin♦ Nov 20 '15 at 18:01
  • I can't recall, are the switch modules treated as a separate device? Like an 880 series router with an embedded AP? One other question, do you get the same result if you use the integrated ports on the router as opposed to ports on a module? – OzNetNerd Nov 20 '15 at 19:06
  • I no longer have access to the router to do any more testing. It will be a while before I can try this again since I'm taking some time off after today. We have a very strict policy where we can't get access to production devices (locked out via TACACS+) without a whole approval process. I can play with stuff as it comes into the bench for configuration before being shipped out, but I don't have anything like that right now. I just happened to be playing with something when I saw this question, but it's gone now. – Ron Maupin♦ Nov 20 '15 at 19:39
  • 1
    How interesting. I wonder if the L3 Switch acts differently than a pure router? – Eddie Nov 21 '15 at 2:49
0

Hope this clarifies any confusion. You have your computer connected to internet through a Cisco router.

Computer()––––––( R )––––––Internet(I)

On the router ( R ) there are two ports involved in forwarding the data to and from internet. Let's say we call the port connected to your LAN as Port1 and the port connected to internet is Port 2.

–––1( R )2–––I

Ip Addresses:

- 10.0.0.10/8
1 - 10.0.0.1/8
2 - 20.0.0.1/8
I - 20.0.0.2/8 (some address on internet)

On the Router ACL can be enforced on either of these ports in either direction (in or out). Let's see what happens in the following cases:

  1. Ping internet ( I ) from your computer (  ).
    1. (  ) sends out an Echo request. >–––1( R )2–––I
    2. The IP packet will have the Source IP Address= 10.0.0.10 and Destination IP Address = 20.0.0.2
    3. Router ( R ) receives the packet on interface ( 1 ). –––>1( R )2–––I
    4. ( R ) checks the routing table and based on that decides to forward the packet to interface 2. –––1( R >)2–––I
    5. Interface ( 2 ) of ( R ) will prepare the packet based on the type of WAN link and send it forward to ( I ) (20.0.0.2) –––1( R )2>–––I
    6. ( I ) receives the packet. –––1( R )2–––>I
    7. ( I ) responds to the packet using a Echo Reply. –––1( R )2––<–I
    8. This packet will have the Source IP Address= 20.0.0.2 and Destination IP Address= 10.0.0.10
    9. Eventually ( R ) will receive the packet on its interface ( 2 ). –––1( R )2<–––I
    10. ( R ) will check the route in its routing table and forward the packet to its interface ( 1 ). –––1(< R )2–––I
    11. Interface ( 1 ) of ( R ) will prepare the packet based on the type of LAN link and send it forward to (  ) (10.0.0.10). –––<1( R )2–––I
    12. (  ) receives the packet. <–––1( R )2–––I
  2. Ping internet ( I ) from your computer ( R ).
    1. ( R ) prepares an Echo request.
    2. ( R ) checks its routing table and concludes that the packet needs to be sent out from interface ( 2 ). –––1( R >)2–––I
    3. As the ( R ) has two interface it can choose to put either of their address as in the Source IP Address field, i.e 10.0.0.1 or 20.0.0.1. It chooses the exit interface IP address as the source by default. This is to simplify the routing process. Extended Ping command can be used to change this behaviour.
    4. So the IP packet will have the Source IP Address= 20.0.0.1 and Destination IP Address = 20.0.0.2.
    5. Interface ( 2 ) of ( R ) will prepare the packet based on the type of WAN link and send it forward to ( I ) (20.0.0.2) –––1( R )2>–––I
    6. ( I ) receives the packet. –––1( R )2–––>I
    7. ( I ) responds to the packet using a Echo Reply. –––1( R )2––<–I
    8. This packet will have the Source IP Address= 20.0.0.2 and Destination IP Address= 20.0.0.1
    9. Eventually ( R ) will receive the packet on its interface ( 2 ). –––1( R )2<–––I

ACL function

  1. When the ACL is bound on interface ( 1 ) in inbound direction –––>|1( R )2–––I
    • The packet –––>1|( R )2–––I will be checked by ACL.
    • –––1|( R >)2–––I will not be checked by ACL.
    • –––1|( R )2<–––I will not be checked by ACL.
    • –––1|(< R )2–––I will not be checked by ACL.
  2. When the ACL is bound on interface ( 1 ) in outbound direction –––1|(< R )2–––I
    • The packet –––>1|( R )2–––I will not be checked by ACL.
    • –––1|( R >)2–––I will not be checked by ACL.
    • –––1|( R )2<–––I will not be checked by ACL.
    • –––1|(< R )2–––I will be checked by ACL.
  3. When the ACL is bound on interface ( 2 ) in inbound direction –––1( R )|2<–––I
    • The packet –––>1( R )|2–––I will not be checked by ACL.
    • –––1( R >)|2–––I will not be checked by ACL.
    • –––1( R )|2<–––I will be checked by ACL.
    • –––1(< R )|2–––I will not be checked by ACL
  4. When the ACL is bound on interface ( 2 ) in outbound direction –––1( R >)|2–––I
    • The packet –––>1( R )|2–––I will not be checked by ACL.
    • –––1( R >)|2–––I will be checked by ACL unless it was generated by ( R ).
    • –––1( R )|2<–––I will not be checked by ACL.
    • –––1(< R )|2–––I will not be checked by ACL.

Note

  • Any packet going out from Router ( R ) to Internet has a chance of Inspection only if the ACL is placed on the path the packet would take ( 2 ) and in the direction the packet would take ( Outbound).
  • Packet being forwarded by Router ( R ) retains the Source IP address of the LAN system unless NATed.
  • Packet generated by Router ( R ) takes the exit interface IP address as source by default (20.0.0.2).

  • Extended Ping command can make the Router ( R ) generate a packet with a different interface IP address as the source (10.0.0.1). Still in this case the packet gets generated inside the Router ( R ) although with the IP Address of the interface where the ACL is bound ( 1 ) it would not be inspected by that ACL.

    TLDR

  • Any packet going out from Router to Destination has a chance of Inspection only if the ACL is placed on the path the packet would take ( exit interface ) and in the direction the packet would take ( Outbound). Unless the packet is generated by the router forwarding the packet.

    Reference

Cisco documentation on ACL.

Improve this answer
1
  • In your ACL explanations, #2 bullet 4 should look more like #4 bullet 2. – YLearn♦ Nov 23 '15 at 14:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.