CCNA online course

What Is an Access Control List (ACL)? Cisco CCNA Guide

Learn how Cisco ACLs filter packets, how standard and extended ACLs differ, wildcard masks, rule order, interface direction, configuration, and verification.

An Access Control List (ACL) is an ordered collection of permit and deny rules used to classify network packets. Routers, firewalls, and other network devices use ACLs for packet filtering: the device examines packet header information and applies a security or traffic-handling policy.

The main security goal is to permit authorized traffic while blocking unauthorized traffic. ACLs can also classify traffic for features such as Network Address Translation (NAT) and Quality of Service (QoS).

What Is an ACL?

An ACL contains individual Access Control Entries (ACEs). Each ACE describes matching conditions and an action:

• Permit: allow matching traffic to continue or be selected by a policy.
• Deny: discard matching traffic when the ACL is being used for interface packet filtering.
• Match conditions: fields such as source address, destination address, protocol, and TCP or UDP port.

ACLs do not inspect the entire application conversation. They generally make decisions from packet header fields, such as IPv4 addresses, the Layer 3 protocol, and transport-layer port numbers.

In Cisco IOS, an ACL has no effect on routed traffic until it is applied to an interface with a direction. Creating an ACL and attaching it to an interface are separate steps.

How Cisco ACL Packet Filtering Works

When a packet reaches an interface and direction where an ACL is applied, the router evaluates the ACL entries from top to bottom.

First-match processing

First-match processing means that the router stops evaluating an ACL as soon as one ACE matches. A later permit cannot override an earlier deny, and a later deny cannot override an earlier permit.

permit ip any any
deny ip any host 192.168.20.10

In this example, the first entry matches all IPv4 traffic, so the deny entry is never reached. Broad entries must be placed carefully because they can hide more specific entries below them.

The implicit deny

Every Cisco ACL has an unseen implicit deny at the end. If no configured ACE matches a packet, the packet is denied. Therefore, an ACL intended to allow normal traffic usually needs an explicit permit for that traffic.

ip access-list standard MGMT-SOURCES
 permit 192.168.10.0 0.0.0.255

This ACL permits the 192.168.10.0/24 source network and implicitly denies every other source. The implicit deny is useful for restrictive policies, but it can also cause accidental outages when required traffic was not explicitly permitted.

Inbound and Outbound ACL Direction

An inbound ACL is evaluated as packets enter a router interface. An outbound ACL is evaluated before packets leave an interface.

• Inbound: the packet is inspected on the interface where it arrives.
• Outbound: the packet is inspected on the interface used to leave the router.

Direction changes which traffic is evaluated and where unwanted traffic is stopped. A packet entering one interface may later leave another interface, so placement must follow the actual routed path.

interface GigabitEthernet0/1
 ip access-group MGMT-SOURCES out

This applies the named ACL in the outbound direction of GigabitEthernet0/1. The same ACL could produce a different practical result if attached to another interface or direction.

General placement guidelines

• Place an extended ACL near the source of the traffic so unwanted traffic can be stopped before it crosses the network.
• Place a standard ACL near the destination because it can match only the source address and may otherwise block that source from reaching other destinations.

These are guidelines, not absolute rules. Routing, redundancy, interface bandwidth, troubleshooting needs, and the exact security requirement can affect the best placement.

Standard ACLs

A Cisco standard IPv4 ACL primarily evaluates the source IPv4 address. It cannot distinguish traffic based on a destination address, application protocol, or TCP/UDP port.

Standard ACLs are therefore suitable when the decision depends only on where traffic came from, such as:

• Allowing a management subnet.
• Denying an untrusted source network.
• Allowing or denying one complete host or subnet.

Wildcard masks

A wildcard mask tells Cisco IOS which address bits must match. A zero bit must match; a one bit is ignored.

• host 192.168.10.10 matches one host and is equivalent to 192.168.10.10 0.0.0.0.
• 192.168.10.0 0.0.0.255 matches the 192.168.10.0/24 network.
• any matches any IPv4 source and is equivalent to 0.0.0.0 255.255.255.255.

ip access-list standard MGMT-SOURCES
 permit 192.168.10.0 0.0.0.255

interface GigabitEthernet0/1
 ip access-group MGMT-SOURCES out

The final implicit deny blocks unmatched source addresses. Whether this interface and direction are correct depends on the topology and the desired policy.

Extended ACLs

An extended IPv4 ACL provides more granular control. It can match:

• Source and destination IPv4 addresses.
• A Layer 3 protocol such as IP, TCP, UDP, or ICMP.
• TCP or UDP source and destination port numbers where applicable.

For example, an extended ACL can permit HTTPS from one workstation to one server while denying other clients. It can also distinguish web access from remote administration such as SSH.

ACL Rule Components

Common keywords include host for one address and any for all addresses. Port operators can include eq for an exact port, as well as operators for ranges, depending on the IOS command syntax and policy.

Practical Scenario: Protecting a Server

Consider this topology:

• Administrator workstation: 192.168.10.10.
• Other user devices: 192.168.10.0/24.
• Router: R1.
• Protected server: 192.168.20.10.

The requirement is that only the administrator workstation may reach the protected server. Other users must be denied, while unrelated traffic should continue if the organization does not intend to block it.

An extended ACL can implement a service-specific policy:

ip access-list extended SERVER-PROTECTION
 permit tcp host 192.168.10.10 host 192.168.20.10 eq 443
 deny ip any host 192.168.20.10
 permit ip any any

interface GigabitEthernet0/0
 ip access-group SERVER-PROTECTION in

The first ACE permits HTTPS from the administrator to the server. The second denies all IP traffic from any source to that server. The final permit allows unrelated IPv4 traffic. Actual placement must match the path by which client traffic enters R1.

Allow all administrator traffic or only one service?

A policy should be as narrow as the requirement allows:

• If the administrator needs only the web application, permit TCP destination port 443.
• If the administrator needs SSH as well, add a separate, specific permit for TCP destination port 22.
• If the administrator genuinely requires all IP communication with the server, use an appropriately scoped IP permit instead of a single HTTPS permit.

Allowing all IP traffic is simpler but provides less restriction. Service-specific permits reduce exposure but require an accurate list of required applications and supporting services.

Return traffic and routing

Testing must account for both directions. The request may pass the ACL while the reply is blocked by another ACL, a server firewall, or an incorrect return route. Confirm that R1 has routes to both networks, the server uses the correct default gateway, the service is running, and any ACL on the return path permits the response.

Other Uses for ACL Matching

ACLs are not used only to enforce interface access rules. In some Cisco features, an ACL acts as a traffic selector:

• NAT: an ACL can identify inside traffic that should be translated.
• QoS: an ACL can classify selected applications or networks for prioritization and other handling.
• Other policy features: ACL-based matching can identify traffic for additional Cisco policies.

Traffic matching and access enforcement are different concepts. An ACL used as a NAT or QoS selector identifies traffic for another feature; it does not automatically mean that unmatched traffic is blocked at an interface.

Verification and Safe Operations

After configuring an ACL, verify both its contents and its attachment:

show access-lists
show ip access-lists
show ip interface GigabitEthernet0/0
show running-config | section access-list

• Confirm that the expected ACEs exist and are in the correct order.
• Confirm the ACL is attached to the intended interface and direction.
• Check match counters where available.
• Test traffic that should be permitted.
• Test traffic that should be denied.
• Check routing, endpoint firewalls, and service availability when results are unexpected.

Use logging selectively, especially on deny entries. Excessive logging can consume device resources, fill a console, or overwhelm a log collector. Document the purpose of each ACL, the networks and services it protects, and the expected exceptions. Review rules periodically and remove entries that are no longer needed.

Common ACL Troubleshooting Problems

All traffic is blocked after applying an ACL

• No explicit permit exists for traffic that should continue.
• Packets are reaching the implicit deny.
• A broad deny appears before a required permit.

Review the ACE order, identify the packet's source, destination, protocol, and port, and add or reposition the required permit before the deny.

The administrator cannot access the protected server

• The administrator or server address is incorrect.
• The extended rule uses the wrong protocol or destination port.
• The ACL is attached to the wrong interface or direction.
• Routing, the server firewall, or service availability is the actual problem.

Check interface attachment, ACL counters, the server's default gateway, and whether the expected service is listening.

A deny rule does not take effect

• An earlier permit matches first.
• The traffic does not traverse the interface where the ACL is applied.
• The rule has an incorrect protocol, address, wildcard mask, or port.

Inspect sequence and hit counters, trace the routed path, and recalculate the wildcard mask. Remember that zero bits must match and one bits are ignored.

Unrelated applications stop working

A server-specific ACL may lack a final permit for traffic outside the intended restriction. Required supporting traffic, such as DNS, DHCP relay, ICMP, or application-specific ports, may also have been omitted. Decide whether unrelated traffic should be allowed, then add narrowly scoped permits for required services.

Exam-Relevant Summary

• An ACL is an ordered list of ACEs that permit or deny matching packets.
• Cisco ACLs use first-match processing.
• An implicit deny exists at the end, so intended traffic often needs an explicit permit.
• An ACL must be applied to an interface in an inbound or outbound direction before it filters routed traffic.
• Standard ACLs primarily match the source IPv4 address.
• Extended ACLs can match protocol, source and destination addresses, and TCP/UDP ports.
• The common guideline is extended ACLs near the source and standard ACLs near the destination.
• host matches one address, any matches all addresses, and wildcard-mask zero bits must match.
• ACLs can enforce access or select traffic for features such as NAT and QoS.

For related fundamentals, review the OSI Reference Model and Computer Network Explained. ACL work also depends on IPv4 addressing, subnetting, Cisco wildcard masks, routed forwarding, and common TCP, UDP, and ICMP behavior.