CCNA online course

Cisco Standard ACLs: Configuration, Placement, and Packet Filtering

Learn how Cisco standard IPv4 ACLs use source addresses, wildcard masks, first-match processing, implicit deny, interface direction, and destination-side placement.

What Is a Standard ACL?

An Access Control List (ACL) is an ordered set of permit and deny rules used to control packet forwarding. Each individual rule is called an Access Control Entry (ACE).

A Cisco standard IPv4 ACL makes its decision using only the packet's source IPv4 address. It does not distinguish between TCP, UDP, ICMP, application ports, or destination addresses. This makes standard ACLs simple and useful for broad source-based policies, but limited for detailed security requirements.

For example, a standard ACL can allow packets sourced by 10.0.0.5, regardless of their destination or transport protocol. An extended ACL can make more granular decisions using additional packet information, such as source and destination addresses, protocol, and TCP or UDP ports.

Because standard ACLs inspect less information, they are generally simpler to configure and may require less processing than more detailed filters. Their simplicity is also their main limitation: if a policy depends on the destination or application, use an extended ACL instead.

How ACL Rules Are Processed

ACL evaluation uses first-match processing. The router compares a packet with the first ACE, then the second ACE, and so on. When an ACE matches, the router immediately performs that ACE's action and stops evaluating the ACL.

1. Start with the first ACE.
2. Compare the packet's source address with the ACE.
3. If the source matches, permit or deny the packet as specified and stop.
4. If it does not match, continue to the next ACE.
5. If no ACE matches, apply the final implicit deny.

The implicit deny is an unstated deny at the end of every ACL. It is not normally displayed as a configured line, but it is always part of the logic. Therefore, traffic not explicitly matched by a preceding permit statement is denied.

Why Rule Order Matters

Suppose an ACL first permits the entire 10.0.0.0/24 network and later denies host 10.0.0.5. The host is permitted because it matches the broad network entry first. The later deny is never reached.

access-list 10 permit 10.0.0.0 0.0.0.255
access-list 10 deny host 10.0.0.5

To give one host different treatment from its network, place the specific host rule before the broad network rule:

access-list 10 deny host 10.0.0.5
access-list 10 permit 10.0.0.0 0.0.0.255

The specific entry is evaluated first, so 10.0.0.5 is denied while other sources in the /24 can match the later permit.

Numbered Standard ACL Ranges and Syntax

Numbered Cisco standard IPv4 ACLs use either of these ranges:

In global configuration mode, the general syntax for a numbered standard ACL entry is:

access-list <acl-number> {permit|deny} <source-ip-address> <wildcard-mask>

• ACL number: Identifies the numbered ACL, such as 1.
• Action: Specifies permit or deny.
• Source IPv4 address: Identifies the source address or source network to match.
• Wildcard mask: Specifies which address bits must match and which may vary.

For one individual source address, Cisco IOS provides the host keyword:

access-list 1 permit host 10.0.0.5

The same exact-host match can be written with a wildcard mask of 0.0.0.0:

access-list 1 permit 10.0.0.5 0.0.0.0

These two entries have the same matching meaning: only source address 10.0.0.5 matches.

Understanding Wildcard Masks

A wildcard mask is an inverse-style mask used by Cisco ACL matching. It is different from a subnet mask. A subnet mask identifies the network and host portions of an address; a wildcard mask tells the ACL which bits must match and which bits are allowed to vary.

• A wildcard bit of 0 requires the corresponding address bit to match.
• A wildcard bit of 1 allows the corresponding address bit to vary.

For an exact host, every bit must match, so every wildcard bit is zero:

access-list 1 permit 10.0.0.5 0.0.0.0

For the source network 10.0.0.0/24, the first three octets must match and the last octet may vary:

access-list 1 permit 10.0.0.0 0.0.0.255

This matches source addresses from 10.0.0.0 through 10.0.0.255. The corresponding subnet mask is 255.255.255.0, but the ACL wildcard mask is 0.0.0.255.

Applying an ACL to a Router Interface

Defining ACL entries does not activate filtering. The ACL must be attached to an interface with the ip access-group command.

interface <interface-id>
ip access-group <acl-number> {in|out}

Inbound processing evaluates traffic as it enters the selected interface. Outbound processing evaluates traffic as it leaves the selected interface. The direction describes the packet's movement through the interface, not merely where the source or destination is physically located.

To select the direction, trace the packet path. If traffic enters R1 from a user network and then leaves R1 through the interface connected to the server network, an ACL applied out on that server-facing interface evaluates the traffic as it exits toward the server.

Where to Place a Standard ACL

The usual guideline is to place a standard ACL as close to the destination as practical. A standard ACL can identify only the source, so placing it near the source may block that source's traffic to every destination reachable through the router.

For example, if a standard ACL denies a workstation's address on its source-side interface, the workstation may be prevented from reaching the server, an Internet connection, and other internal networks. If the policy concerns only a protected server network, applying the ACL on the interface leading to that network limits the effect to traffic headed there.

This guideline is not an absolute substitute for packet-path analysis. Choose the interface and direction where the ACL sees the traffic you intend to filter. If the policy must distinguish destinations, protocols, or ports, use an extended ACL rather than trying to force that policy into a standard ACL.

Protected-Server Configuration Scenario

Consider this topology:

• Administrator workstation: 10.0.0.5/24
• Other user: 172.16.0.10/24
• Protected server: 192.168.0.5/24
• R1 interface toward the server network: FastEthernet0/1

The policy is to allow the administrator's source address to reach the server-side network while preventing unauthorized sources from reaching it. A standard ACL can enforce this as a source-based decision. It cannot distinguish whether the administrator is accessing one particular server or another destination on the same outgoing path.

The following configuration permits the administrator, explicitly denies the named user, and applies ACL 1 outbound on the server-facing interface:

R1# configure terminal
R1(config)# access-list 1 permit 10.0.0.5 0.0.0.0
R1(config)# access-list 1 deny 172.16.0.10 0.0.0.0
R1(config)# interface FastEthernet0/1
R1(config-if)# ip access-group 1 out
R1(config-if)# end

The first entry could also use the host keyword:

access-list 1 permit host 10.0.0.5

The explicit deny for 172.16.0.10 makes that part of the policy visible. It is not required to block that source when no later permit exists: the final implicit deny would also block it. In this configuration, every source other than 10.0.0.5 is denied.

Because ACL 1 is applied outbound on FastEthernet0/1, the packet must be routed toward that interface before the ACL evaluates it. The destination-side placement keeps this source-only policy focused on traffic headed toward the server network.

Verification

After configuration, verify both the ACL contents and its interface attachment.

R1# show access-lists
R1# show ip interface FastEthernet0/1

show access-lists displays the ACL entries and their order. On platforms that maintain counters, increasing match counts can help confirm that traffic is reaching a particular ACE.

show ip interface FastEthernet0/1 reports whether an access list is applied inbound or outbound on the interface. Confirm that it identifies ACL 1 in the expected direction.

Then test from relevant source hosts:

• From 10.0.0.5, test reachability to 192.168.0.5. The traffic should be permitted by the first ACE.
• From 172.16.0.10, test the same destination. The traffic should be denied by the explicit deny.
• From another source, expect denial because no permit matches and the implicit deny applies.

Interpret failures in the context of the ACL's scope. A standard ACL matches only the source address. It does not permit a particular destination or service independently of the source.

Troubleshooting Standard ACLs

The administrator cannot reach the server

• Check that the permit uses the correct source address, such as 10.0.0.5.
• Check the wildcard mask. An exact host requires 0.0.0.0 or the host keyword.
• Look for an earlier deny or broad matching statement. First-match processing may stop evaluation before the intended permit.
• Confirm that ACL 1 is attached to the server-facing interface.
• Confirm that the direction is out for packets leaving R1 toward the server network.
• Remember that creating the ACL without applying it does not filter traffic; conversely, applying the wrong ACL can produce an unexpected result.

More users are blocked than expected

If the ACL contains only a permit for 10.0.0.5, every other source is blocked by the implicit deny. Review the intended policy and add explicit permit entries only for sources that should be allowed.

Also validate the wildcard mask. A mask that is narrower or broader than intended can match too few or too many source addresses.

A later permit does not allow a source

An earlier matching ACE has already ended evaluation. Re-read the ACL from top to bottom for the affected source address. Move a specific host rule before a broader network rule when the host needs different treatment.

Traffic to other destinations is unexpectedly blocked

A standard ACL placed near the source affects that source's traffic to multiple destinations because it cannot inspect the destination address. Where appropriate, move the ACL closer to the protected destination. If the policy needs destination- or protocol-specific control, use an extended ACL.

Key Takeaways

• A standard IPv4 ACL filters using only the packet's source IPv4 address.
• Each ACE is evaluated from top to bottom, and the first matching ACE determines the action.
• Every ACL ends with an implicit deny, so unmatched traffic is denied.
• Numbered standard ACLs use ranges 1-99 and 1300-1999.
• A wildcard bit of zero requires a match; a wildcard bit of one allows variation.
• Use host 10.0.0.5 or 10.0.0.5 0.0.0.0 for an exact host.
• Creating an ACL does not apply it. Attach it with ip access-group in the appropriate direction.
• Place standard ACLs close to the destination when practical because source-only filtering can affect other destinations.
• Use verification commands to check entries, order, interface attachment, and direction.

Before practicing ACLs, review computer networking fundamentals, the OSI reference model, and IPv4 addressing and subnetting concepts.