Last updated · reviewed for accuracy
ACLs in IOS
An access control list is a packet filter written as a list of permit and deny lines, read top to bottom, first match wins. The line you cannot see (the implicit deny everything at the bottom) causes more outages than the lines you can.
Standard ACLs: filter by source only
A standard ACL matches only the source address. Numbered 1-99, it should be applied close to the destination, because it cannot tell where traffic is going, only where it came from.
! allow the staff subnet, block one troublesome host R1(config)# access-list 10 deny host 10.0.10.99 R1(config)# access-list 10 permit 10.0.10.0 0.0.0.255
Order matters: with the permit first, the deny would never be reached. The subnet permit already matched the host. First match wins, evaluation stops.
Extended ACLs: source, destination, protocol, port
Extended ACLs (100-199) match source, destination, protocol and port, so they can express real policy: who may reach which service. Apply them close to the source to kill unwanted traffic early.
! guests may browse the web, but not reach the staff subnet R1(config)# access-list 120 deny ip 10.0.20.0 0.0.0.255 10.0.10.0 0.0.0.255 R1(config)# access-list 120 permit tcp 10.0.20.0 0.0.0.255 any eq 443 R1(config)# access-list 120 permit udp 10.0.20.0 0.0.0.255 any eq 53
Read each line out loud left to right: action, protocol, source + wildcard, destination + wildcard, port. If you can say it, you understand it.
The invisible line at the bottom
Every IOS ACL ends with an implicit deny any that you never see in the config. A packet that matches no line is dropped. An ACL with only deny lines therefore blocks everything, including you.
This is the classic self-inflicted outage: an admin adds an ACL with two deny lines to block two hosts, applies it, and the interface goes dark, because everything else hit the invisible deny any. If your intent is “block these, allow the rest,” the last line you write must be an explicit permit any (or permit ip any any in extended lists).
Apply it, then verify it
An ACL does nothing until applied to an interface with ip access-group, in a direction: in filters traffic arriving at the interface, out filters traffic leaving it. show access-lists shows match counters per line.
R1(config)# interface GigabitEthernet0/1 R1(config-if)# ip access-group 120 in R1(config-if)# end R1# show access-lists 120 Extended IP access list 120 10 deny ip 10.0.20.0 0.0.0.255 10.0.10.0 0.0.0.255 (14 matches) 20 permit tcp 10.0.20.0 0.0.0.255 any eq 443 (311 matches)
The match counters are your truth serum: a rule with zero matches after a day of traffic is either unnecessary or (more often) written wrong.
ACLs appear twice in this curriculum
This lesson covers the IOS syntax. The Security track’s firewall lesson covers the policy side, where filtering belongs in a network and what stateful firewalls add that ACLs cannot.
Frequently asked questions
Why did my ACL block all traffic?
Every IOS ACL ends with an invisible implicit deny any. A packet matching none of your lines is dropped, so an ACL of only deny lines blocks everything. Add an explicit permit for what should survive.
What is the difference between a standard and an extended ACL?
Standard (1–99): source only, place near the destination. Extended (100–199): source, destination, protocol and port, place near the source.
Does the order of ACL lines matter?
Completely. Evaluation is top-to-bottom, first match wins, then stops. Put specific lines first, general lines last: a broad permit above a narrow deny makes the deny dead code.