When “deny any” doesn’t deny all!

| Monday, December 27th, 2010 | 9 Comments »

I recently came across this discussion and thought I’d shed some light. A user wants to deny all traffic outbound a specific interface. Let’s say it is ethernetO. The best way to test this is to create an ACL and apply it to your interface outbound, and ping out from an internal device. You won’t be able to.

config t
access-list 1 deny any

interface e0
ip access-group 1 OUT

Simple enough, but ping tests from the router itself reveals that you can still indeed ping! Why?

How about trying to ping from a loopback interface?

ping 4.2.2.2 source loopback 0

The result is that you can still ping out!

The reason is that ACL’s are applied to packets as they traverse an interface. Pings from the router itself don’t fall into that category. I believe that management from the router including pings are provided by the control plane versus the data plane where ACL’s are applied to.

So there you go. If you have any further insights on this please let me know. And if I’m wrong, please let me know as well! Make sure you test your ACL’s from either INSIDE or OUTSIDE of the router, not using the router itself to test your ACL’s.

Share
  • http://twitter.com/LBSources LBSources

    You know it’s funny you posted about this topic. I too would like to learn more about this. I ran into a similar situation where an ACL is applied sub-interface (DMZ) for outbound allowed traffic and at the end is a “deny any any”.. This network where the sub-interface (DMZ) lived was able to still get out to the internet, but not the other sub-interfaces/VLANs identified in the ACL (outbound). I still am a little fuzzy on how this works, but from what I’ve been told is the same thing. The ACL only affects traffic as it traverses an interface. That being the case, hosts behind that sub-interface/VLAN can still get out to the internet..

  • Ivan Pepelnjak

    Traffic generated by the router is not filtered by outbound ACLs. The behavior hasn’t changed in the last 20 years.

  • http://twitter.com/brandontek Brandon Kim

    Ivan, is it safe to say that traffic generated by the router exists on the control plane? Therefore ACL’s aren’t applied to them?

  • http://twitter.com/brandontek Brandon Kim

    That is an interesting issue. If you’d like to share your config, we can lab it up and see where the issue is. You should be able to treat the SVI just like any other physical interface when applying the ACL unless I’m missing something…..

  • http://twitter.com/LBSources LBSources

    @Brandon .. @JohnLockie stated the same thing and linked me to some Wiki articles. The fact that packets never left the control plane cause the traffic was generated by the router. In my case the packets traversed to a different sub-interface/SVI at which point it gets into the forwarding/data plane which is why it would be denied access per the ACL. However; traffic looking to reach the internet will not be policed by the ACL since it has been sourced by the router. Still has me sort of fuzzy.

  • http://twitter.com/LBSources LBSources

    True indeed – You can, but in this case the ACL doesn’t affect outbound traffic to the internet, just local traffic from traversing the other VLANS..

  • http://twitter.com/brandontek Brandon Kim

    Fuzzy indeed, but thank you for bringing this to my attention. I will try to come up with my own lab with your scenario and see if I can replicate it. Surely you are not the only one that has encountered this issue. I’ll let you know when my lab is complete and ping you!

  • http://twitter.com/LBSources LBSources

    Here goes my GNS3 lab that helped me grasp the understanding. I used VPCS to simulate the hosts :)

    http://www.uploadhookup.com/index.php/files/get/_vWqz-GqSQ/acl-control-plane-forwarding-plane.rar

  • http://twitter.com/brandontek Brandon Kim

    Perfect timing, I am actually going to setup GNS3 on a server tomorrow. I can import this and take a look. I can also test with physical hardware to rule out any possible bugs in GNS…..