CCNA IPv4 ACLs: Standard, Extended, Numbered and Named Access Lists

An IPv4 access control list is an ordered list of permit and deny entries (access control entries, ACEs) that a router compares against a packet's header fields. Once applied to an interface in a direction, it decides whether each packet crossing that interface is forwarded or dropped. ACLs are also used to select traffic for other features (vty access, NAT, QoS, route filtering); this lesson covers their use as packet filters and on vty lines.

Processing follows three rules, and almost every troubleshooting question comes down to one of them:

1. Top-down. Entries are checked in sequence-number order, starting with the lowest. (In standard ACLs IOS may store and display single-host entries ahead of range entries for speed, but it only does so where the first-match result cannot change.)
2. First match wins. As soon as a packet matches an entry, that entry's action (permit or deny) is taken and no further entries are checked. A broad entry placed above a specific one shadows it: the specific entry can never be reached for the packets the broad one already matched.
3. Implicit deny. Every ACL ends with an invisible deny any (standard) or deny ip any any (extended). A packet that matches no entry is dropped. An ACL that contains only deny entries therefore blocks everything; it needs at least one permit, usually a final permit any or permit ip any any.

Example: in an ACL whose entry 10 is permit ip 172.20.0.0 0.0.255.255 any and entry 20 is deny tcp host 172.20.7.40 any eq 3389, a Remote Desktop packet from 172.20.7.40 matches entry 10 first and is permitted. Entry 20 never fires. The fix is ordering: a specific exception must sit above the broad rule it is an exception to.

ACLs are stateless: each packet is judged on its own headers, with no memory of the connection it belongs to. That is why return traffic needs its own thought (see the section on established).

A standard ACL matches only the packet's source IPv4 address. An extended ACL matches the protocol, the source and destination addresses, and for TCP and UDP the source and destination ports (plus options such as ICMP message types and the established keyword). If a requirement mentions a destination, an application or a port, only an extended ACL can express it.

The number tells IOS which type a numbered ACL is: access-list 50 and access-list 1999 are standard, access-list 101 and access-list 2699 are extended. Numbers outside the four ranges belong to other protocols or are not valid IPv4 ACL numbers. Names carry no such meaning, so a named ACL declares its type in the ip access-list standard or ip access-list extended command.

The syntax differs accordingly. A standard entry has no protocol field and no destination: permit any, deny host 192.168.40.9, deny 192.168.40.0 0.0.0.255. An entry that names a protocol and a destination is extended syntax: typed in ip access-list standard mode, IOS rejects it.

A wildcard mask tells the router which bits of the address to check: a 0 bit means "must match" and a 1 bit means "ignore". It is not a subnet mask. For a contiguous block, the wildcard is the inverse of the subnet mask: subtract each octet of the mask from 255.

Two shorthands replace the common cases: host A.B.C.D equals the address with wildcard 0.0.0.0, and any equals 0.0.0.0 255.255.255.255. They are interchangeable in both standard and extended entries.

Common errors that IOS accepts without complaint:

• A subnet mask typed as a wildcard. 192.168.7.9 255.255.255.255 ignores every bit and matches any address; 192.168.40.0 255.255.255.0 checks only the last octet. IOS reads the second value as a wildcard whatever it looks like.
• The wrong block size. The wildcard for a prefix is the block size minus one in the interesting octet. A /21 has a third-octet block of 8, so its wildcard is 0.0.7.255; 0.0.15.255 would cover a /20 (twice the range) and 0.0.8.255 is not a contiguous block at all. The base address must also sit on a block boundary (a multiple of 8 here).
• A host address with a network wildcard. permit 192.168.30.45 0.0.0.255 matches all of 192.168.30.0–192.168.30.255. IOS normalises the entry by zeroing the ignored bits, so show access-lists displays permit 192.168.30.0, wildcard bits 0.0.0.255. The display reveals what the entry really matches.

Non-contiguous wildcards are legal because each bit is evaluated independently. Read them octet by octet: a 0 octet must match, a 255 octet is ignored. If every branch numbers its management loopback 172.<region>.<branch>.1 inside 172.16.0.0/12, the entry 172.16.0.1 0.15.255.0 fixes the last octet at .1 and ignores the region and branch values, matching the loopback of every branch with one line. A wildcard can also pick alternate blocks: 10.8.1.0 0.0.254.255 ignores every third-octet bit except the lowest, so it matches only the odd-numbered /24s in 10.8.0.0/16. Such entries match exactly what the bits say, so check them against the addressing plan.

The classic guideline is: put a standard ACL as close to the destination as possible, and an extended ACL as close to the source as possible. Both follow from what the ACL can see.

• A standard ACL matches only the source. Placed near the source, deny 192.168.40.0 0.0.0.255 would stop that subnet from reaching everything, not just the protected destination. Placed outbound on the interface facing the protected LAN, it affects only traffic heading there.
• An extended ACL can name the destination and application, so it can drop unwanted packets at the first router they reach. Placing it inbound on the source's LAN interface stops the packets before they consume WAN bandwidth and router CPU along the path.

The guideline gives way to real constraints. A standard ACL near the source cannot block one destination while allowing others, because it never looks at the destination. So when the only router you may change sits on the source side, the job needs an extended ACL there that names the destination. And when a requirement is about protecting the path itself (bandwidth, CPU on routers in between), only filtering where the traffic enters the network meets it, whatever ACL type is used.

An ACL does nothing until it is applied. On an interface the command is ip access-group {number | name} {in | out}, entered in interface configuration mode.

• in filters packets as they arrive on the interface, before the router makes a routing decision.
• out filters packets the router is forwarding out of that interface, after routing.

Think from the router's point of view: traffic from a user LAN arrives in on the LAN interface, while traffic toward that LAN leaves out of it.

Rules that decide many questions:

• One IPv4 ACL per interface per direction. Entering a second ip access-group … in on the same interface silently replaces the first; IOS does not merge or chain them. To filter both SNMP and TFTP in one direction, put both entries in one ACL.
• Outbound ACLs do not filter traffic the router itself originates (a ping or SSH session typed on the router's CLI, routing updates it sends). Transit traffic is filtered; locally generated packets bypass the outbound check.
• Inbound ACLs do filter traffic addressed to the router, which leads to the control-plane surprises covered below.
• An applied ACL that does not exist filters nothing. ACL names are case-sensitive. ip access-group Mgmt-Filter in when the configured ACL is MGMT-FILTER is accepted without error and shows up in show ip interface, but because Mgmt-Filter is undefined, IOS permits all traffic on that interface. The same happens if you delete an ACL that is still bound.

access-class is a different command used only on vty lines, and ipv6 traffic-filter applies IPv6 ACLs; neither applies an IPv4 ACL to an interface.

Why can an inbound ACL break routing protocols and the router's own pings?

An inbound ACL checks every packet arriving on the interface, including packets addressed to the router itself. When an ACL ends in a deny, any control-plane traffic not explicitly permitted is dropped:

• Routing protocols. OSPF hellos are sent to the multicast address 224.0.0.5 using IP protocol 89. An inbound ACL that permits only user traffic drops them, and the adjacency goes down once the dead interval expires. The permit must use the ospf protocol keyword (OSPF runs directly over IP, so no TCP or UDP entry can match it), take the neighbour as the source, and use a destination that covers the multicast group, such as any or host 224.0.0.5; for example permit ospf host 172.31.5.2 any on a link where the neighbour is 172.31.5.2. A destination of only the router's own interface address misses hellos sent to 224.0.0.5. Place it above the final deny.
• Replies to the router's own traffic. A ping typed on R1 leaves without an outbound check, but the echo-reply from the neighbour arrives inbound and is dropped by an inbound ACL that does not permit it. The narrow fix permits only ICMP echo-replies from the neighbour to the router's link address, for example permit icmp host 172.31.5.2 host 172.31.5.1 echo-reply when the router is 172.31.5.1: source = the neighbour, destination = the router, message type = reply.

Before applying a restrictive inbound ACL on a routed link, list what the router itself needs to receive there: routing-protocol packets, replies to its own pings and management sessions, and any management traffic such as SSH to the router.

An extended entry follows a fixed order: action, protocol, source, [source port], destination, [destination port], [options].

access-list 130 deny tcp 192.168.40.0 0.0.0.255 host 192.168.90.20 eq 80

Here tcp is the protocol, 192.168.40.0 0.0.0.255 the source, host 192.168.90.20 the destination and eq 80 the destination port.

A port operator belongs to whichever address it follows. eq 80 after the destination matches destination port 80 (an HTTP request to the server). The same eq 80 written after the source matches source port 80, which a browser opening a connection never uses. Requests from clients to servers almost always match on the destination port; the client's source port is a random high port.

Key elements:

• Protocol keywords: ip (any IPv4 packet), tcp, udp, icmp, and routing protocols such as ospf (IP protocol 89) and eigrp (88). Ports exist only for tcp and udp; OSPF and ICMP have none, so "tcp … eq 89" does not match OSPF.
• Port operators: eq (equal), neq, gt (greater than), lt (less than) and range low high. gt 21 matches 22 and every higher port, so it is not an exact match for SSH; eq is the only operator that matches one port.
• Port names: IOS accepts names such as www (80), telnet (23), domain (53) and ftp (21), and may display them in show output instead of the number.
• Match TCP vs UDP correctly. DNS lookups use UDP 53 (TCP 53 is used for large responses and zone transfers), so an ACL permitting only tcp … eq 53 breaks name resolution. SSH is TCP 22, Telnet TCP 23, HTTP TCP 80, HTTPS TCP 443, TFTP UDP 69, SNMP UDP 161, NTP UDP 123.
• ICMP types: echo is a ping request and echo-reply its answer, e.g. permit icmp any any echo-reply.

Choosing the narrowest entry means narrowing every field the requirement names: the protocol (tcp or udp, not ip), the destination (host, or the address with wildcard 0.0.0.0, when one server is meant), and the port (eq). For "SSH from the admin /28 to one jump host only": permit tcp 172.20.250.0 0.0.0.15 host 192.168.90.22 eq 22. Widening any one field matches more than the requirement allows.

Evaluating a packet against an extended ACL means checking every field of each entry in order. A packet from 172.20.6.9 to UDP 161 matches deny udp 172.20.0.0 0.0.255.255 any eq snmp even if a later entry permits 172.20.6.0/23 to the same port: the earlier entry is broader and wins. A packet whose protocol appears in no entry (for example GRE in an ACL of only TCP and UDP entries) falls to the implicit deny.

No. IOS ACLs are stateless, so an inbound ACL on an internet-facing interface also judges the replies to connections your users opened. If an inbound ACL on the internet link of a publicly addressed LAN 203.0.113.0/24 permits only tcp any host 203.0.113.25 eq 25 (an inbound mail server), the users' outbound web sessions break: the replies come from the web servers' ports to the users' high ports and hit the implicit deny.

The established keyword on a TCP entry matches segments that have the ACK or RST bit set. Every segment of an open TCP session except the very first SYN carries ACK, so

permit tcp any 203.0.113.0 0.0.0.255 established

lets return traffic reach the users while a new inbound connection attempt (a bare SYN) still falls through to the deny. It is a flag check, not a state table: the router does not track sessions, and a crafted packet with ACK set would also match. Real session tracking needs a stateful firewall feature, which is beyond this topic. established applies only to TCP; UDP replies (such as DNS answers) need their own entries.

An entry that permits a server port toward the users' range is not the same thing: a port match ignores the flags, so it admits brand-new connections to that port on every user host.

Every entry in an IOS ACL has a sequence number, shown by show access-lists. By default, entries are numbered 10, 20, 30…, and an entry entered without a sequence number is appended at the end (the last number plus 10), which places it after any final deny ip any any where it can never match.

In ACL configuration mode (ip access-list extended CORE-FILTER, which also works for numbered ACLs, e.g. ip access-list extended 140):

• Insert an entry by giving it a number between two existing ones: 35 deny udp host 172.20.7.40 any eq 69 lands between 30 and 40 and is evaluated before 40.
• Delete a single entry with no <seq>, e.g. no 40. The rest of the ACL and its interface binding stay in place.
• Resequence when there is no free number between two entries: ip access-list resequence CORE-FILTER 100 10 (global mode; the arguments are the starting number and the increment) renumbers the entries 100, 110, 120… in their existing order, opening gaps for new inserts. Entries keep their order; only their numbers change.

A worked case: entries 31, 32, 33 and 34 leave no number between 32 and 33. After resequencing with start 100 and increment 10, they become 100, 110, 120 and 130, so an entry that must run before old entry 33 (now 120) is added as 115.

Two destructive commands to avoid when only one line must change: no ip access-list extended CORE-FILTER deletes the whole ACL (the interface then references an undefined ACL and permits everything), and in global mode no access-list 140 … on a numbered ACL removes the entire ACL 140, not just the matching line. no ip access-group unbinds the ACL from the interface but leaves it defined.

To control who can open a management session to the router itself, apply a standard (or extended) ACL to the vty lines with access-class <acl> in:

access-list 8 permit 172.20.250.0 0.0.0.15
line vty 0 15
 access-class 8 in
 transport input ssh

This restricts sessions arriving on any interface, because it is checked when a session reaches a vty line, and it does not affect transit traffic routed through the router. Applying ip access-group on every interface instead would also filter user traffic passing through.

• access-class … in filters incoming vty sessions by source address. access-class … out filters the sessions a user on the router opens from it to other devices; it does not protect the router.
• The class must be on every vty line. Routers usually have lines 0–15, and the running configuration often shows them as two blocks, line vty 0 4 and line vty 5 15, each with its own settings. IOS assigns an incoming session to the lowest free line, so if only the first block carries the access-class, the filter holds only while a free line remains in that block; once those lines are busy, the next session lands on an unfiltered line. Editing the ACL cannot close that gap, because a line without an access-class never consults the ACL.
• The implicit deny applies here too: everything not permitted by ACL 8 is refused.

Three commands answer the three questions you always ask: what does the ACL say, is it matching, and where is it applied?

Reading the evidence:

• The implicit deny has no counter. To count and log dropped packets, add an explicit final entry such as 90 deny ip any any log. It drops exactly what the implicit deny dropped, so the ACL's behaviour is unchanged, but now drops are counted and logged. The action matters as much as the log keyword: a final permit would change what the ACL allows.
• Zero matches on every entry usually means the ACL is not where the traffic is: bound in the wrong direction, on the wrong interface, or not bound at all. Read the direction lines of show ip interface against the requirement: an ACL meant for traffic from a LAN must appear as the inbound list on that LAN's interface. If it shows as the outgoing list there, it is checking traffic routed toward the LAN, and packets arriving from the LAN pass unfiltered.
• An ACL bound but no traffic filtered at all can mean the bound name does not match a defined ACL (names are case-sensitive).
• clear access-list counters [name] resets the counters so a fresh test shows only new matches. It changes nothing about filtering.