Understanding Access Control Lists

Introduction

Welcome to Part 14 of the Network Fundamentals study notes! If you haven’t already, we recommend watching the video first.

Sometimes we need to control which traffic is allowed to flow through our network — blocking access to sensitive resources, limiting non-business traffic, or restricting which devices can manage a router. Access Control Lists, or ACLs, are the tool for the job.

What is an ACL?

An ACL is a list of rules. Each rule is called an ACE (Access Control Entry). Each ACE contains match criteria and an action — either permit (allow the traffic) or deny (block it).

Match criteria can include any combination of: source IP address, destination IP address, protocol (TCP, UDP, IP, etc.), and port numbers.

How ACLs Are Evaluated

Rules are evaluated in order, from top to bottom, using sequence numbers. When a packet arrives, the router compares it against each rule in sequence. The moment a match is found, the action is applied and evaluation stops. No further rules are checked. This is the first match wins principle — and it means the order of your rules matters enormously.

The Implicit Deny

At the very end of every ACL sits an invisible rule: the implicit deny. If a packet doesn’t match any of your configured rules, this hidden rule drops it automatically. You’ll never see it in the list, but it’s always there.

This is a good security default — if you haven’t explicitly allowed something, it’s blocked. But it also means you need to think carefully about what traffic you’re allowing, and make sure you haven’t accidentally blocked something you need (like ping, for example).

Wildcard Masks

ACL rules use wildcard masks to specify address ranges — and they can look confusingly similar to subnet masks, but they work differently.

In a wildcard mask: 0 bits mean the corresponding address bit must match, and 1 bits mean the corresponding bit can be anything. So 0.0.0.255 means “match the first three octets exactly, don’t care about the last one” — useful for matching an entire /24 subnet.

Unlike subnet masks, wildcard bits don’t have to be grouped together. This allows advanced matching — for example, a mask of 0.0.255.0 could match a specific host address (.x.y.1) across many subnets. In practice this is rare, but it’s worth understanding.

Standard vs Extended ACLs

There are two main types of ACL:

• Standard ACL – can only match on the source IP address. Simple, but limited. Created first by Cisco.
• Extended ACL – can match on source address, destination address, protocol (IP, TCP, UDP), and port numbers. Far more flexible and the type you’ll use most.

Numbered vs Named ACLs

Numbered ACLs

The older method. Each ACL is identified by a number, and entries sharing that number belong to the same list. The number range determines the type:

• 1–99 and 1300–1999 → standard ACL
• 100–199 and 2000–2699 → extended ACL

The number itself doesn’t matter beyond putting you in the right range — it’s just a label. These ranges are worth memorising for exams.

Named ACLs

The modern, preferred method. Instead of a number, you give the ACL a meaningful name (e.g. SERVER-ACL). No number ranges to worry about — you simply specify standard or extended during configuration. Named ACLs use a sub-configuration mode where entries are added inside the list. They’re easier to read, easier to manage, and support sequence numbers for inserting rules anywhere in the list.

Applying ACLs to Interfaces

An ACL does nothing on its own — it must be applied to a router interface to have any effect. When you apply it, you also specify the direction:

• Ingress (in) – traffic arriving at the interface, coming into the router
• Egress (out) – traffic leaving the router through the interface

Only one ACL per interface per direction is allowed. The command is ip access-group <acl-name-or-number> <in|out>.

Understanding the direction is critical. Think about the path the packet travels. If you apply an ACL in the wrong direction, it may not catch the traffic you intend.

Practical Tips

• Test thoroughly – ACLs are easy to misconfigure. The implicit deny may block traffic you didn’t intend to block (ping is a common victim). Always test after changes.
• Match counters – use show access-lists to see how many times each rule has been matched. This is invaluable for verifying that your ACL is working as expected. Note: the implicit deny doesn’t have a counter — another reason to add an explicit deny rule when you need visibility into dropped traffic.
• Remarks – add comments to your ACL with the remark keyword. These appear in show access-lists output and make it much easier to understand what each rule does when you come back to it later.
• log keyword – adding log to the end of an ACE makes the router generate a log entry each time that rule matches. Useful for troubleshooting, but avoid leaving it on permanently as it reduces router performance.
• The host keyword – when matching a single IP address, use host <ip> instead of writing the full wildcard mask — it’s cleaner and less error-prone.

ACLs vs Firewalls

ACLs on a router provide basic packet filtering — they look at packet headers and apply permit/deny rules. Firewalls go much further. They perform stateful inspection, tracking the state of connections rather than just individual packets. They can also inspect the contents of packets, not just the headers — detecting malware, application-layer attacks, and more.

The choice depends on the situation. A firewall makes sense at the network edge or anywhere you need deep inspection. A router ACL is often more appropriate for internal traffic control — blocking management access from certain devices, restricting traffic between VLANs, and similar tasks. In many networks, you’ll use both.

Resources

Test your knowledge with the Introduction to Networking quizzes.