Access Control Lists (ACL): A Simple Guide for Beginners

PitsPits
21 min read

Access Control Lists, or ACLs, are an important part of network security. They help control who can access a network or certain resources by setting rules about what traffic is allowed or blocked. If you’re new to networking, ACLs might sound complicated, but they’re actually easy to understand once you break them down. In this blog, I’ll explain what ACLs are, how they work, and why they matter in everyday network management.


What is an ACL and Why Do We Use It?

An Access Control List (ACL) is basically a set of rules that control the flow of network traffic. Think of it like a filter or a gatekeeper that decides which data packets can pass through and which ones get blocked. These rules help protect the network by allowing only trusted traffic and stopping anything unwanted.

We use ACLs to improve security, manage network traffic, and make sure resources are used properly. For example, an ACL can block access to sensitive parts of a network or limit which devices can communicate with each other.

In short, ACLs give network administrators control over who can access what, helping to keep the network safe and efficient.


How Does an ACL Work?

An ACL works by checking each data packet against a list of rules in order. These rules say whether to allow or deny the packet based on things like its source or destination address, protocol type, or port number.

When a packet arrives, the ACL looks at the rules one by one until it finds a match. Once it does, it either lets the packet through or blocks it. If no rule matches, the packet is usually denied by default to keep the network safe.

This process happens quickly and helps control traffic on routers, switches, or firewalls, making sure only the right data moves through the network.


How Are ACLs Applied?

ACLs are applied to network devices like routers or switches, usually on specific interfaces. You can attach an ACL to an interface in either the inbound or outbound direction. Inbound means the ACL checks traffic coming into the device, while outbound means it checks traffic leaving the device.

By applying ACLs this way, you control what traffic is allowed or blocked as it enters or leaves a particular part of the network.


What’s the Maximum Number of ACLs on an Interface?

Most devices allow you to apply one inbound ACL and one outbound ACL per interface. That means each interface can have up to two ACLs applied: one for incoming traffic and one for outgoing traffic.


What is an ACE?

ACE stands for Access Control Entry. Think of an ACE as a single rule within an ACL. Each ACE defines whether to permit or deny specific types of traffic based on criteria like IP addresses, protocols, or ports.

An ACL is made up of multiple ACEs, and the device checks each packet against these entries in order.


What is Implicit Deny?

At the end of every ACL, there is an automatic rule called the implicit deny. This means that if a packet doesn’t match any of the ACEs, it is denied by default.

Because of implicit deny, it’s important to make sure your ACL includes rules to allow the traffic you want. Otherwise, everything else gets blocked.


Types of ACLs

Now that you know what an ACL is and how it works, let’s look at the different types of ACLs you might come across.

ACLs can be grouped into several types based on how they filter traffic and where they are used. Understanding these types will help you choose the right ACL for your network needs.

Next, we’ll go over the main types of ACLs and what makes each one different.


Standard ACLs

Standard ACLs are the simplest type. They filter traffic only based on the source IP address. This means they allow or block packets depending on where they come from, but they don’t look at the destination or type of traffic.

Because standard ACLs are limited in what they check, they are usually applied close to the destination device to avoid blocking needed traffic too early.

Standard ACLs use numbers from 1 to 99 (and 1300 to 1999 for extended range).

Key points:

  • Matches only the source IP address

  • Cannot filter by protocol, destination, or port

  • Usually applied near the destination to avoid unwanted blocking


Extended ACLs

Extended ACLs are more flexible and powerful. They can filter traffic based on several things, including:

  • Source and destination IP addresses

  • Protocol type (like TCP, UDP, ICMP)

  • Port numbers (like HTTP on port 80 or FTP on port 21)

This lets you create more specific rules, such as allowing only web traffic from one network to another, while blocking everything else.

Extended ACLs use numbers from 100 to 199 (and 2000 to 2699 for extended range).

Key points:

  • Matches source and destination IP addresses

  • Can filter by protocol and port numbers

  • Usually applied close to the source to block unwanted traffic early


Numbered ACLs

Numbered ACLs are the traditional way to identify ACLs using a number. As mentioned before, standard ACLs use numbers from 1 to 99 (and 1300 to 1999 for extended), while extended ACLs use numbers from 100 to 199 (and 2000 to 2699 for extended).

When you create or manage ACLs, you refer to them by these numbers. This method is simple but can get confusing if you have many ACLs, since numbers don’t describe what the ACL does.


Named ACLs

Named ACLs let you give your ACL a descriptive name instead of a number. This makes it easier to manage and remember what each ACL is for, especially in larger networks.

With named ACLs, you can create, edit, or delete specific rules without removing the whole ACL. This adds flexibility compared to numbered ACLs.

Both standard and extended ACLs can be created as named ACLs.


Standard Numbered ACLs: Explanation and Configuration

Standard Numbered ACLs focus only on the source IP address to decide whether to allow or block traffic. Because they don’t check the destination or type of traffic, they’re best used when you want to control access based on where the traffic is coming from.

Why use Standard Numbered ACLs?
They are useful when you need a simple way to restrict access from specific devices or networks. For example, you might want to block all traffic coming from a particular IP address or allow traffic only from a trusted subnet.

One important thing to remember is that standard ACLs should be applied as close to the destination as possible. This helps avoid accidentally blocking other traffic that should be allowed because standard ACLs only check the source address.


How to Configure a Standard Numbered ACL

Here’s a basic example of how to create a standard numbered ACL on a Cisco router:

Router(config)# access-list 10 deny 192.168.1.5
Router(config)# access-list 10 permit any
  • The first line blocks traffic from the IP address 192.168.1.5.

  • The second line allows all other traffic.

After creating the ACL, you apply it to an interface, specifying the direction (inbound or outbound):

Router(config)# interface GigabitEthernet0/1
Router(config-if)# ip access-group 10 in

This applies ACL number 10 to inbound traffic on the GigabitEthernet0/1 interface.


This setup blocks traffic from the specific IP but lets everything else through. Remember, if traffic doesn’t match any rule, it’s blocked by the implicit deny rule at the end.


Checking ACLs with the show access-list Command

Once you’ve created and applied ACLs, you’ll want to verify that they’re working as expected. The show access-list command helps you do this by displaying the details of all ACLs configured on your device.

When you run this command, you’ll see each ACL listed with its entries (ACEs), including whether they permit or deny traffic and what IP addresses or protocols they match.

Here’s an example of how to use it:

Router# show access-list

The output will look something like this:

Standard IP access list 10
    deny   192.168.1.5
    permit any

This output shows ACL number 10 with two entries: one denying traffic from 192.168.1.5 and one permitting all other traffic.

Using show access-list is a quick way to review your ACL rules and confirm they’re applied correctly.


Moving to Standard Named ACLs

We’ve talked about standard numbered ACLs and how they work. Now let’s look at another way to manage ACLs that’s often easier using Standard Named ACLs.

Instead of identifying ACLs by numbers, named ACLs let you give your ACL a meaningful name. This makes it simpler to organize and update your rules, especially when working with many ACLs.


Standard Named ACLs: Explanation and Configuration

Standard Named ACLs work the same way as standard numbered ACLs, they filter traffic based only on the source IP address. The main difference is that you give the ACL a descriptive name instead of a number. This helps keep things organized and easier to manage.


Why Use Standard Named ACLs?

Named ACLs make it easier to remember what each ACL does, especially in larger networks. They also allow you to edit or add rules without deleting the entire ACL, giving you more flexibility.


How to Configure a Standard Named ACL

Here’s a simple example of how to create a standard named ACL on a Cisco router:

Router(config)# ip access-list standard BlockIP
Router(config-std-nacl)# deny 192.168.1.5
Router(config-std-nacl)# permit any
Router(config-std-nacl)# exit

In this example:

  • BlockIP is the name of the ACL.

  • The first rule blocks traffic from 192.168.1.5.

  • The second rule allows all other traffic.

After creating the named ACL, apply it to an interface just like with numbered ACLs:

Router(config)# interface GigabitEthernet0/1
Router(config-if)# ip access-group BlockIP in

This applies the named ACL BlockIP to inbound traffic on the interface.


Named ACLs give you more control and make managing ACLs simpler as your network grows.


Should You Apply Standard ACLs Inbound or Outbound?

When it comes to applying standard ACLs whether numbered or named, the general rule is to apply them as close to the destination as possible, usually on the inbound direction of the interface closest to where you want to control or block traffic.

Here’s why:

  • Standard ACLs filter only by source IP address. If you apply them near the source (outbound interface), you might block more traffic than intended because you’re not considering where the traffic is going.

  • Applying them inbound near the destination helps make sure you only block unwanted traffic reaching that specific point, reducing accidental blocks.


Summary

ACL TypeBest Direction to ApplyReason
Standard NamedInbound, near destinationFilters only source IP, so applied close to destination to avoid blocking too much traffic early.
Standard NumberedInbound, near destinationSame reason as named ACLs.

In short, for both standard named and numbered ACLs, apply them inbound on the interface closest to the destination you want to protect.


Moving on to Extended ACLs

Before we dive into extended ACLs, here’s something useful to know:

On modern Cisco IOS devices, you can create numbered ACLs just like named ACLs. This means you can use the same commands and get the same flexibility whether you choose to use numbers or names for your ACLs.

So, whether you stick with numbered ACLs or switch to named ones, the configuration process is very similar.


Example: Numbered ACL Configured Like a Named ACL

Instead of the old style:

Router(config)# access-list 100 permit tcp any any eq 80
Router(config)# access-list 100 deny ip any any

You can configure it like this:

Router(config)# ip access-list extended 100
Router(config-ext-nacl)# permit tcp any any eq 80
Router(config-ext-nacl)# deny ip any any
Router(config-ext-nacl)# exit

In this example:

  • 100 is the ACL number (extended range).

  • The ACL permits TCP traffic on port 80 (HTTP) from any source to any destination.

  • It then denies all other IP traffic.

This shows how numbered ACLs can now be configured with the same flexibility as named ACLs.

Now, let’s move on to Extended ACLs, which give you more control by filtering traffic based on source and destination addresses, protocols, and ports.


Understanding Extended ACLs

Now that you know numbered ACLs can be configured like named ones, let’s take a closer look at Extended ACLs.

Extended ACLs are more powerful because they let you filter traffic based on multiple criteria not just the source IP, but also destination IP, protocols like TCP or UDP, and even port numbers.

This gives you much more control over what traffic is allowed or blocked, making extended ACLs ideal for managing complex network access.


Extended ACLs: What You Need to Know

Extended ACLs let you filter traffic based on multiple criteria like:

  • Source IP address

  • Destination IP address

  • Protocol type (TCP, UDP, ICMP, etc.)

  • Port numbers (for example, HTTP uses port 80, FTP uses port 21)

This gives you more control over network traffic than standard ACLs.


Extended ACL Number Ranges

  • 100 to 199 — Standard extended ACL numbers

  • 2000 to 2699 — Expanded extended ACL numbers (for newer devices)

  • For named ACLs, you just pick a name instead of a number.


Where to Apply Extended ACLs

Extended ACLs are usually applied close to the source of the traffic on the inbound or outbound interface so unwanted traffic gets blocked before it travels deeper into the network.


How to Configure an Extended Numbered ACL

Here’s an example that allows web traffic (HTTP) from one subnet to another and blocks everything else.

Router(config)# access-list 110 permit tcp 192.168.1.0 0.0.0.255 10.0.0.0 0.0.0.255 eq 80
Router(config)# access-list 110 deny ip any any
  • access-list 110 — Creates ACL number 110 (an extended ACL)

  • permit tcp — Allows TCP protocol traffic

  • 192.168.1.0 0.0.0.255 — Source network with wildcard mask (matches 192.168.1.x)

  • 10.0.0.0 0.0.0.255 — Destination network with wildcard mask (matches 10.0.0.x)

  • eq 80 — Specifies port 80 (HTTP)

  • deny ip any any — Denies all other IP traffic


Applying the ACL to an Interface

Apply the ACL to an interface and specify direction:

Router(config)# interface GigabitEthernet0/1
Router(config-if)# ip access-group 110 out
  • interface GigabitEthernet0/1 — Selects the interface

  • ip access-group 110 out — Applies ACL 110 to outgoing traffic on that interface


This setup lets HTTP traffic from the 192.168.1.x network to the 10.0.0.x network but blocks everything else.


Matching Protocols in Extended ACLs

One of the powerful features of extended ACLs is the ability to filter traffic by protocol type and even by specific port numbers. This lets you allow or block particular kinds of traffic, like web browsing, email, or file transfers.


Common Protocols and Their Ports

Here are some common protocols you might filter in an ACL, along with their well-known port numbers:

ProtocolDescriptionCommon Port(s)
TCPTransmission Control Protocol — reliable connectionPorts vary by service, e.g., HTTP (80), HTTPS (443), FTP (21), SSH (22)
UDPUser Datagram Protocol — faster, no connectionDNS (53), DHCP (67, 68), TFTP (69)
ICMPInternet Control Message Protocol — used for ping and error messagesNo ports (uses types and codes instead)

How to Match Protocols in ACLs

When creating an extended ACL, you specify the protocol after the permit or deny keyword. For example:

access-list 110 permit tcp any any eq 80

This permits TCP traffic on port 80 (HTTP) from any source to any destination.


Examples for Different Protocols

  • Allow HTTP traffic (TCP port 80):

      access-list 110 permit tcp any any eq 80
    
  • Allow HTTPS traffic (TCP port 443):

      access-list 110 permit tcp any any eq 443
    
  • Allow DNS traffic (UDP port 53):

      access-list 110 permit udp any any eq 53
    
  • Allow ping requests (ICMP echo):

      access-list 110 permit icmp any any echo
    
  • Allow SSH traffic (TCP port 22):

      access-list 110 permit tcp any any eq 22
    

Using protocol and port matching in extended ACLs helps you control traffic with precision.


When to Use host in ACLs

In ACLs, the keyword host is used when you want to specify a single IP address instead of a range or subnet.

Normally, when you write an ACL rule, you provide an IP address and a wildcard mask. The wildcard mask tells the device which bits to ignore, so it can match a range of addresses. But if you want the rule to match exactly one IP address, you use host before the IP.


Why Use host?

  • To allow or block traffic from a specific device

  • When you want to be precise and not include any other IPs

  • To prevent accidentally matching other addresses in a subnet


Example

If you want to block traffic from just the IP address 192.168.1.5, you can write:

access-list 10 deny host 192.168.1.5

This matches only that single IP.

Without host, you would write:

access-list 10 deny 192.168.1.5 0.0.0.0

The 0.0.0.0 wildcard mask means “match exactly this address,” which is the same as using host.

Using host just makes your ACL rules easier to read when you mean a single IP.


Understanding Wildcard Masks in ACLs

Wildcard masks are used in ACLs to specify which bits of an IP address should be checked and which can be ignored. They help define ranges or groups of IP addresses.


How Wildcard Masks Work

  • A wildcard mask works opposite to a subnet mask.

  • A 0 bit means "check this bit exactly."

  • A 1 bit means "ignore this bit; it can be anything."

For example, the wildcard mask 0.0.0.255 means:

  • The first three octets must match exactly.

  • The last octet can be any number between 0 and 255.

So, when you write:

192.168.1.0 0.0.0.255

It matches any IP from 192.168.1.0 to 192.168.1.255.


Using Wildcard Masks in ACLs

Here’s an example to allow traffic from the entire 192.168.1.0/24 network:

access-list 10 permit 192.168.1.0 0.0.0.255

This means all IPs in that subnet are permitted.

Quick Tip:

If you want to match a single IP address, use a wildcard mask of 0.0.0.0, or simply use host before the IP.


Example 1: Allow HTTP Traffic from One Network to Another

access-list 110 permit tcp 192.168.1.0 0.0.0.255 10.0.0.0 0.0.0.255 eq 80
  • What it does: Allows TCP traffic on port 80 (HTTP) from any device in the 192.168.1.0/24 network to any device in the 10.0.0.0/24 network.

  • Technique: Uses wildcard masks to specify source and destination subnets, and filters by protocol and port.


Example 2: Deny a Specific Host from Using FTP

access-list 110 deny tcp host 192.168.1.5 any eq 21
  • What it does: Blocks FTP traffic (TCP port 21) from the specific host with IP 192.168.1.5 to anywhere.

  • Technique: Uses the host keyword to match a single IP address and filters by protocol and port.


Example 3: Permit ICMP (Ping) from Any Source to a Specific Host

access-list 110 permit icmp any host 10.0.0.10 echo
  • What it does: Allows ICMP echo requests (ping) from any source to the specific host 10.0.0.10.

  • Technique: Matches a specific protocol (ICMP), uses any for source, and host for a single destination IP with a specific ICMP type (echo).

These examples show how you can combine different elements; wildcard masks, the host keyword, protocols, ports, and ICMP types to create precise rules in your extended ACLs.


Matching TCP and UDP Port Numbers

Now that you’ve seen how to create extended ACL entries using IP addresses, protocols, and keywords like host, let’s dive deeper into matching specific TCP and UDP port numbers.

Ports help identify particular services or applications on a device like web browsing on port 80 or email on port 25. Being able to filter by these ports means you can control exactly what kind of traffic is allowed or blocked.


Matching TCP and UDP Ports in ACLs

When creating extended ACLs, you can specify port numbers to control traffic for particular services. This is done by adding keywords like eq (equal), gt (greater than), or range after the source or destination IP.


Common Port Matching Keywords

  • eq [port] — Matches traffic on a specific port

  • gt [port] — Matches traffic on ports greater than the specified port

  • lt [port] — Matches traffic on ports less than the specified port

  • range [start] [end] — Matches traffic within a range of ports


Examples

  • Allow HTTP traffic (TCP port 80):

      access-list 110 permit tcp any any eq 80
    
  • Block all TCP traffic to ports greater than 1024:

      access-list 110 deny tcp any any gt 1024
    
  • Allow UDP traffic for DNS (port 53):

      access-list 110 permit udp any any eq 53
    
  • Allow TCP traffic on ports 20 to 21 (FTP):

      access-list 110 permit tcp any any range 20 21
    

Using port matching in your ACLs gives you more precise control over network traffic, letting you allow or block specific services as needed.


Important Note on Port Matching and Permitting Traffic

When you use port matching in ACLs, remember that it only applies to the traffic you explicitly permit. If a packet doesn’t match any of the permit rules, it will be denied by default because of the implicit deny at the end of every ACL.

That means if you want to allow traffic on certain ports, you need to be sure to include rules that permit all the necessary ports and protocols. Otherwise, traffic not matching those rules will be blocked.

For example, if you permit HTTP (port 80) but forget to permit HTTPS (port 443), HTTPS traffic will be denied.


Example 1: Allow TCP Traffic on Ports Greater Than 1024

access-list 120 permit tcp any any gt 1024
  • Allows TCP traffic from any source to any destination where the destination port is greater than 1024.

  • Useful for permitting high-numbered ephemeral ports used by many applications.


Example 2: Deny UDP Traffic on Ports Less Than 1024

access-list 120 deny udp any any lt 1024
  • Blocks UDP traffic to ports less than 1024, which are often reserved for well-known services.

  • This could be used to restrict access to certain system services.


Example 3: Permit TCP Traffic on All Ports Except Port 22 (SSH)

access-list 120 permit tcp any any neq 22
  • Allows TCP traffic on all ports except port 22, which is commonly used for SSH.

  • This is useful if you want to block SSH access while allowing other TCP traffic.


Example 4: Permit TCP Traffic on a Range of Ports (e.g., 1000 to 2000)

access-list 120 permit tcp any any range 1000 2000
  • Permits TCP traffic on ports between 1000 and 2000 inclusive.

  • Useful for allowing multiple services within a port range.


Example Scenario: Using an Extended ACL in Cisco IOS

Imagine you want to control traffic between two networks:

  • Source network: 192.168.10.0/24

  • Destination network: 10.0.0.0/24

You want to:

  • Allow HTTP traffic (TCP port 80) from the source to the destination

  • Block all other traffic between these networks


Step 1: Create the Extended ACL

On your Cisco router, enter global configuration mode and create ACL number 110 with these commands:

Router# configure terminal
Router(config)# access-list 110 permit tcp 192.168.10.0 0.0.0.255 10.0.0.0 0.0.0.255 eq 80
Router(config)# access-list 110 deny ip 192.168.10.0 0.0.0.255 10.0.0.0 0.0.0.255
Router(config)# access-list 110 permit ip any any
Router(config)# exit
  • The first line allows HTTP traffic from the source subnet to the destination subnet.

  • The second line blocks all other IP traffic between these two networks.

  • The third line allows all other traffic from or to anywhere else, so the ACL doesn’t block unrelated traffic.


Step 2: Apply the ACL to an Interface

Suppose the traffic from the source network enters the router on interface GigabitEthernet0/1. You apply the ACL inbound on that interface like this:

Router# configure terminal
Router(config)# interface GigabitEthernet0/1
Router(config-if)# ip access-group 110 in
Router(config-if)# exit
Router(config)# exit

This means the router will check incoming packets on GigabitEthernet0/1 against ACL 110.


Step 3: Verify the ACL

To see the ACL entries and hit counts (how many times each rule matched), use:

Router# show access-list 110

Example output might look like:

Extended IP access list 110
    10 permit tcp 192.168.10.0 0.0.0.255 10.0.0.0 0.0.0.255 eq 80 (5 matches)
    20 deny ip 192.168.10.0 0.0.0.255 10.0.0.0 0.0.0.255 (3 matches)
    30 permit ip any any

This simple example shows how to create, apply, and verify an extended ACL that allows HTTP traffic between two subnets while blocking everything else between them.


Advantages of Named ACLs and Resequencing

Named ACLs offer several benefits over numbered ACLs:

  • You can give ACLs meaningful names, making it easier to identify their purpose.

  • Named ACLs allow you to edit, add, or remove specific rules without deleting the entire ACL.

  • They improve management, especially in larger networks with many ACLs.


How to Resequence a Named ACL

Resequencing lets you insert new rules at specific positions without rewriting the whole ACL. This is handy for maintaining order and clarity.

Here’s how you can resequence a named ACL:

Router# ip access-list extended BlockWeb
Router(config-ext-nacl)# resequence 10 5 50
  • 10 is the starting sequence number.

  • 5 is the increment between sequence numbers.

  • 50 is the ending sequence number.

This command renumbers entries starting at 10, increasing by 5, up to 50. It helps create space for inserting new rules in the future.


Best Placement of ACLs in a Network

  • Standard ACLs should be applied close to the destination. Because they filter only on the source IP, applying them near the destination helps avoid accidentally blocking legitimate traffic early.

  • Extended ACLs should be applied close to the source. Since they filter on source, destination, protocol, and port, blocking unwanted traffic early saves bandwidth and reduces unnecessary load on the network.


Wrap-Up

Access Control Lists are essential tools for managing and securing network traffic. Understanding the difference between standard and extended ACLs, how to configure them (both numbered and named), and where to apply them in your network makes a big difference in keeping your network safe and efficient.

Remember, using named ACLs and resequencing helps you manage rules more easily, especially as your network grows. Always plan your ACL placement carefully to avoid unintentional traffic blocks.

With this knowledge, you’re ready to start using ACLs confidently to control network access and protect your systems.

0
Subscribe to my newsletter

Read articles from Pits directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Pits
Pits