VMware ESXi and vSphere Cluster Management

What Is an Access Control List (ACL)? Cisco ACL Basics

Learn how Cisco access control lists filter packets, how standard and extended ACLs differ, wildcard masks, placement, configuration, and verification.

What Is an Access Control List?

An Access Control List (ACL) is an ordered collection of packet-matching rules. Each rule can permit, deny, or classify traffic according to a defined policy. An individual rule is called an Access Control Entry (ACE).

ACLs are commonly used for packet filtering on routers, multilayer switches, firewalls, and other network devices. They can restrict communication between networks, hosts, and services—for example, allowing an administrator to use SSH while preventing other clients from reaching a protected server.

ACLs are one security control layer. They do not replace host security, user authentication, encryption, endpoint protection, or a stateful firewall policy.

How ACL Packet Filtering Works

When an ACL is used for interface filtering, the device compares packet fields with each ACE. Depending on the ACL type, those fields can include source and destination IP addresses, the IP protocol, and TCP or UDP port numbers.

Permit, Deny, and the Implicit Deny

A permit ACE allows traffic that matches it. A deny ACE rejects matching traffic. Cisco ACLs also behave as though an unlisted deny exists at the end. This is called the implicit deny.

For example, an ACL containing only permit host 192.0.2.10 allows that host but rejects every other source that reaches the end of the list. An explicit permit any or permit ip any any may be needed when other traffic should continue.

Inbound and Outbound ACLs

ACLs are associated with an interface and a traffic direction.

• Inbound: evaluated as traffic arrives at an interface, before the router forwards it through that interface.
• Outbound: evaluated after the routing decision, before traffic leaves an interface.

The correct direction depends on where the traffic enters and exits the device. A correctly written ACL can still appear ineffective if it is attached to the wrong interface or direction.

Standard ACLs

A Cisco standard ACL primarily matches the IPv4 source address. It can answer a question such as, “Which source hosts may send traffic?” It cannot normally distinguish the destination, application protocol, or TCP/UDP service in the way an extended ACL can.

Standard ACLs are relatively simple to configure, but their source-only scope can be broad. If a standard ACL denies a source, it may deny that source from reaching every destination covered by the ACL's placement.

Numbered and Named Standard ACLs

A numbered standard ACL uses a numeric range traditionally associated with standard IPv4 ACLs, such as 1–99 and 1300–1999. A named standard ACL uses a descriptive name and configuration mode:

ip access-list standard ADMIN_ONLY
 permit host 192.0.2.10
 deny any

The explicit deny any documents the intended policy, although traffic would also be rejected by the implicit deny after the permitted host entry.

Extended ACLs

An extended ACL provides more precise matching. It can match:

• Source and destination IPv4 addresses
• Layer 3 protocol information, including IP, ICMP, and other supported protocols
• TCP and UDP traffic
• TCP or UDP source and destination ports

TCP and UDP ports identify transport-layer services. For example, TCP port 22 is commonly used by SSH, TCP port 23 by Telnet, and TCP port 443 by HTTPS.

Extended ACLs support granular policies such as “permit TCP from the administrator host to this server on port 22, but reject other traffic to that server.” Their precision also creates more configuration complexity and may require additional processing compared with a simple source-only check.

Numbered and Named Extended ACLs

Numbered extended ACLs traditionally use ranges such as 100–199 and 2000–2699. Named extended ACLs use a descriptive name, which makes the configuration easier to identify:

ip access-list extended SERVER_ACCESS
 permit tcp host 192.0.2.10 host 198.51.100.20 eq 22
 deny ip any host 198.51.100.20
 permit ip any any

The first entry allows only SSH from the administrator workstation to the server. The second denies other IPv4 traffic to that server. The final permit allows unrelated IPv4 traffic to continue; without it, unrelated traffic would reach the implicit deny.

Standard ACL vs. Extended ACL

ACL Placement and Interface Direction

A common design guideline is to place a standard ACL closer to the destination. Because it identifies only sources, placing it too close to the source may block that source from reaching destinations that should remain available.

Place an extended ACL closer to the source when practical. Its ability to identify the destination, protocol, and port allows unwanted traffic to be stopped before it crosses more of the network.

These are guidelines rather than automatic rules. The final placement must reflect the policy, routing path, device capabilities, and operational risk. Confirm that required traffic—including routing, DNS, monitoring, and remote administration—will not be unintentionally blocked.

ACL Matching Syntax

Addresses, Host, and Any

• Explicit address: identifies an address using an address and, where required, a wildcard mask.
• host: identifies exactly one address, such as host 192.0.2.10.
• any: matches every address in that field.
• Wildcard mask: tells Cisco which address bits must match and which may vary.

A wildcard mask is an inverse-style mask. In a wildcard mask, a bit of 0 means the corresponding address bit must match; a bit of 1 means that bit can vary.

• 192.0.2.10 0.0.0.0 matches one host, equivalent to using host 192.0.2.10.
• 192.0.2.0 0.0.0.255 matches the entire 192.0.2.0/24 subnet.
• 0.0.0.0 255.255.255.255 matches any IPv4 address, equivalent to any.

For a contiguous subnet, the wildcard is commonly the inverse of the subnet mask. A /24 mask of 255.255.255.0 corresponds to wildcard 0.0.0.255.

Protocols and Port Operators

Extended ACLs can identify a protocol and, for TCP or UDP, compare a port. Common operators include:

• eq: equal to a port or named service, such as eq 22
• gt: greater than a port
• lt: less than a port
• neq: not equal to a port
• range: a continuous range, such as range 8000 8080

For example, permit tcp any host 198.51.100.20 eq 443 permits TCP traffic from any source to that server's HTTPS port. Port operators are relevant to protocols that use ports, principally TCP and UDP.

Security Scenario: Least-Privilege Server Access

Consider a topology with an administrator PC at 192.0.2.10, other client hosts, router R1, and a protected server at 198.51.100.20. A least-privilege policy should allow only the administrator to use SSH to the server, reject other access to that server, and allow unrelated traffic if the broader network policy requires it.

A standard ACL can permit the administrator's source address, but it cannot limit that permission to only the protected server or only SSH. If applied near the server, it may allow the administrator to reach other destinations through that interface as well. An extended ACL is appropriate when the policy must identify both the destination and the service.

ip access-list extended SERVER_ACCESS
 remark Allow only administrator SSH to the protected server
 permit tcp host 192.0.2.10 host 198.51.100.20 eq 22
 remark Block other traffic to the protected server
 deny ip any host 198.51.100.20
 remark Preserve unrelated IPv4 traffic
 permit ip any any
interface GigabitEthernet0/0
 ip access-group SERVER_ACCESS in

The exact interface and direction depend on the topology. If the ACL is placed on an interface where traffic enters from the administrator and other clients, inbound filtering may be suitable. If the traffic path differs, select the interface and direction through which the relevant packets actually travel.

Permit SSH and Deny Telnet

A management policy might permit a management subnet to use TCP port 22 while denying Telnet on TCP port 23:

ip access-list extended MANAGEMENT
 permit tcp 192.0.2.0 0.0.0.255 any eq 22
 deny tcp any any eq 23
 permit ip any any

The final permit makes the remaining policy explicit. In a stricter design, other required services would be listed individually and the final action could intentionally rely on the implicit deny.

Uses Beyond Interface Packet Filtering

ACL matching is also used by features that classify traffic rather than directly accept or reject packets at an interface.

• NAT: an ACL can identify inside-subnet traffic eligible for translation or exclude traffic destined for a protected or VPN network. In this case, the ACL's permit and deny results are interpreted by NAT; they do not necessarily mean “forward” and “drop.”
• QoS: an ACL can classify traffic for marking, queuing, rate treatment, or other Quality of Service policies.
• Platform-specific services: routing, management, VPN, and other device features may consume ACL matches for their own policy decisions.

Always distinguish an ACL attached with ip access-group, which filters interface traffic, from an ACL referenced by another feature.

Verification and Safe Operations

Inspect both the ACL definition and its interface binding. Cisco IOS-style commands include:

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

• Review ACE order and confirm that specific permits appear before broader denies.
• Check match counters where the platform displays them. A counter can show whether traffic has reached an entry.
• Verify the interface and direction with show ip interface.
• Test from both permitted and denied endpoints.
• Use remark entries to document the purpose of important rules.
• Use a lab or change-control process before applying a production ACL.

Troubleshooting ACL Problems

Expected Traffic Is Blocked

Common causes include a missing permit, the final implicit deny, an ACL on the wrong interface or direction, or a broad deny that appears before the intended permit. Inspect the order and counters, verify the binding, and compare the actual source, destination, protocol, and port with the ACE.

One Server's ACL Blocks Too Much

This often occurs when a standard ACL is used for a destination-specific policy or when unrelated traffic has no explicit permit. Use an extended ACL when the destination or service matters, and add required unrelated permits after the protected-server rules.

Remote Management Is Lost

Check whether SSH from the actual management source is permitted and whether TCP port 22 is being filtered in the correct direction. Use console or out-of-band access to restore service, add a narrowly scoped management permit before broader denies, and retest before saving the configuration.

A Rule Does Not Match

Review the wildcard mask, actual packet addresses, protocol, and port. Also inspect all earlier ACEs: an earlier match may be deciding the result before the apparently correct rule is reached.

Key Takeaways

• An ACL is an ordered set of ACEs that permits, denies, or classifies traffic.
• Cisco interface ACLs use top-down, first-match processing and an implicit deny at the end.
• Inbound ACLs are checked as packets enter an interface; outbound ACLs are checked before packets leave.
• Standard ACLs primarily match IPv4 source addresses.
• Extended ACLs can match source and destination addresses, protocols, and TCP/UDP ports.
• Standard ACLs are generally placed closer to the destination; extended ACLs are generally placed closer to the source.
• Rule order, wildcard masks, interface direction, and explicit permits are frequent sources of errors.
• ACLs should support—not replace—authentication, encryption, host security, and firewall policy.

For a concise reference to this subject, see ACL access control list basics.