Cisco ACL Configuration: Standard, Extended and Named ACLs

Access control lists, or ACLs, allow Cisco routers to permit or deny packets based on defined conditions. A correct Cisco ACL configuration requires three decisions: what traffic to match, where to place the ACL and which interface direction to use.

This guide focuses on IPv4 ACLs used in CCNA router labs. It covers numbered standard and extended ACLs, named ACLs, wildcard masks, practical configurations and troubleshooting.

What Is an Access Control List on a Cisco Router?

An access control list is an ordered set of permit and deny statements used to classify network traffic. A router checks packets against the entries from top to bottom, uses the first matching entry and stops processing that packet.

ACLs can filter traffic passing through a router, restrict management access and identify traffic for features such as Network Address Translation. This article concentrates on interface packet filtering.

Every ACL follows four important rules:

1. Entries are processed from top to bottom.
2. The first matching entry decides the result.
3. Every ACL has an invisible deny any at the end.
4. An ACL does nothing until it is applied to an interface or referenced by another feature.

The invisible final statement is called the implicit deny. If permitted traffic does not match an explicit permit statement, the router drops it.

How Does a Router Process an ACL?

A router evaluates an inbound ACL after receiving a frame and before making the routing decision. It evaluates an outbound ACL after selecting the exit interface but before transmitting the packet.

Consider this diagram in words:

PC-A --- G0/0 [R1] G0/1 --- Server
          inbound   outbound

A packet sent from PC-A to the server enters R1 through G0/0 and leaves through G0/1. An ACL applied in on G0/0 sees the packet as it enters, while an ACL applied out on G0/1 sees it just before it reaches the server network.

For return traffic, the directions reverse:

Server --- G0/1 [R1] G0/0 --- PC-A
            inbound   outbound

The words in and out are always relative to the router interface, not the user or the internet.

A Cisco router normally supports one IPv4 ACL per interface, per direction and per protocol. Applying a second IPv4 ACL in the same direction replaces the earlier application, so combine the required rules into one ACL.

What Is the Difference Between Standard, Extended and Named ACLs?

Standard ACLs match only the source IPv4 address, while extended ACLs can match source, destination, protocol and port numbers. Named ACLs use descriptive names and can be either standard or extended.

Named ACLs are not a separate filtering category. Their main benefits are readable names, sequence numbers and easier rule editing.

Standard ACLs are normally placed near the destination because they cannot distinguish between different destination networks. Extended ACLs are normally placed near the source so unwanted traffic is dropped before it crosses other links. These are design guidelines rather than absolute rules.

Understanding the routing path is essential before choosing an ACL interface. Review how routers select an exit interface in Static vs Dynamic Routing if the packet path is unclear.

How Do Wildcard Masks Work in Cisco ACLs?

A wildcard mask tells the router which address bits must match and which bits can vary. A wildcard bit of 0 means compare the corresponding bit, while a bit of 1 means ignore it.

For normal contiguous subnet masks, subtract each octet from 255:

Subnet mask:   255.255.255.0
Wildcard mask:   0.  0.  0.255

Common examples are:

Do not enter a subnet mask where IOS expects a wildcard mask. Using 255.255.255.0 as a wildcard creates a very different match.

How Do You Configure a Standard ACL?

A standard ACL permits or denies packets according to their source IPv4 address. Because it cannot check the destination, it should usually be applied near the protected destination.

Use this lab topology:

User LAN                     Server LAN
192.168.10.0/24              172.16.20.0/24
       |                           |
     G0/0 --- R1 Router --- G0/1
192.168.10.1                 172.16.20.1

The requirement is to stop host 192.168.10.50 from reaching the server LAN while allowing other sources. Configure ACL 10 and apply it outbound on G0/1:

R1# configure terminal
R1(config)# access-list 10 deny host 192.168.10.50
R1(config)# access-list 10 permit any
R1(config)# interface gigabitEthernet 0/1
R1(config-if)# ip access-group 10 out
R1(config-if)# end

The first statement denies packets sourced by 192.168.10.50. The second statement is necessary because the implicit deny would otherwise block every other source as well.

This ACL blocks the host from all destinations reached through G0/1. It cannot block only SSH to one server because a standard ACL does not inspect protocols, ports or destination addresses.

Verify the configuration:

R1# show access-lists 10
Standard IP access list 10
    10 deny   host 192.168.10.50
    20 permit any

R1# show ip interface gigabitEthernet 0/1
GigabitEthernet0/1 is up, line protocol is up
  Outgoing Common access list is 10
  Inbound  access list is not set

IOS may display sequence numbers even when the ACL was created with the older numbered syntax.

How Do You Configure an Extended ACL?

An extended ACL can filter by source address, destination address, IP protocol and transport-layer port. It gives more precise control and is generally placed close to the traffic source.

Suppose host 192.168.10.50 must be blocked from using SSH to server 172.16.20.10, but all other IP traffic must continue. Apply this ACL inbound on the user-facing interface:

R1# configure terminal
R1(config)# access-list 110 deny tcp host 192.168.10.50 host 172.16.20.10 eq 22
R1(config)# access-list 110 permit ip any any
R1(config)# interface gigabitEthernet 0/0
R1(config-if)# ip access-group 110 in
R1(config-if)# end

Read the deny statement from left to right:

deny | TCP | source host | destination host | destination port 22

The keyword tcp is required because SSH uses TCP. The final permit ip any any allows other IPv4 traffic, including other TCP and UDP applications.

Common extended ACL port syntax includes:

permit tcp 192.168.10.0 0.0.0.255 host 172.16.20.10 eq 443
permit udp 192.168.10.0 0.0.0.255 host 172.16.20.53 eq domain
permit icmp 192.168.10.0 0.0.0.255 172.16.20.0 0.0.0.255

eq 443 matches HTTPS traffic with destination port 443. The domain keyword represents port 53, but DNS may use both UDP and TCP, so complete DNS filtering may require separate entries for each protocol.

ACLs on traditional Cisco IOS routers are stateless packet filters. A permit rule for a client request does not automatically create a state table that permits every related return packet. The applied interfaces and directions determine whether separate return-path rules are needed.

How Do You Configure and Edit a Named ACL?

A named ACL uses a descriptive identifier instead of only a number. Named configuration mode also makes it easier to add or remove individual entries by sequence number.

The following policy permits HTTPS to an application server and DNS to a DNS server. It denies other traffic from the user LAN to the server LAN, logs those matches and then allows traffic to unrelated destinations.

R1# configure terminal
R1(config)# ip access-list extended USER-TO-SERVERS
R1(config-ext-nacl)# 10 permit tcp 192.168.10.0 0.0.0.255 host 172.16.20.10 eq 443
R1(config-ext-nacl)# 20 permit udp 192.168.10.0 0.0.0.255 host 172.16.20.53 eq domain
R1(config-ext-nacl)# 30 permit tcp 192.168.10.0 0.0.0.255 host 172.16.20.53 eq domain
R1(config-ext-nacl)# 40 deny ip 192.168.10.0 0.0.0.255 172.16.20.0 0.0.0.255 log
R1(config-ext-nacl)# 50 permit ip any any
R1(config-ext-nacl)# exit
R1(config)# interface gigabitEthernet 0/0
R1(config-if)# ip access-group USER-TO-SERVERS in
R1(config-if)# end

To allow SSH from the administrator PC, insert a rule before sequence 40:

R1# configure terminal
R1(config)# ip access-list extended USER-TO-SERVERS
R1(config-ext-nacl)# 35 permit tcp host 192.168.10.25 host 172.16.20.10 eq 22
R1(config-ext-nacl)# end

To remove only that entry:

R1(config)# ip access-list extended USER-TO-SERVERS
R1(config-ext-nacl)# no 35

Do not use no ip access-list extended USER-TO-SERVERS unless the intention is to delete the entire ACL.

How Can You Verify a Cisco ACL Configuration?

ACL verification should confirm the entries, sequence order, interface, direction and match counters. Test both traffic that should be permitted and traffic that should be denied.

Useful commands include:

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

Example counter output:

Extended IP access list USER-TO-SERVERS
    10 permit tcp 192.168.10.0 0.0.0.255 host 172.16.20.10 eq 443 (18 matches)
    40 deny ip 192.168.10.0 0.0.0.255 172.16.20.0 0.0.0.255 log (6 matches)
    50 permit ip any any (41 matches)

A rising counter proves that traffic matched the entry. A zero counter may mean the test traffic did not use that path, the address or port is wrong, or an earlier statement matched first.

Counters can be cleared before a controlled test:

R1# clear access-list counters USER-TO-SERVERS

The configuration and verification workflow is practised in a structured CCNA course, together with addressing, switching, routing and network services.

Why Is a Cisco ACL Not Working?

Most ACL faults are caused by incorrect order, direction, placement, wildcard masks or missing permit statements. Troubleshoot the packet path systematically rather than changing several rules at once.

Use this checklist:

1. Confirm basic connectivity. Check interface status, IP addressing and routing before blaming the ACL.
2. Identify the ingress and egress interfaces. Use the routing table and topology to follow the packet.
3. Check the applied direction. Verify in or out with show ip interface.
4. Read entries from top to bottom. A broad rule may match before a specific rule.
5. Check the wildcard mask. Confirm that the intended source and destination fall inside the matched range.
6. Check the protocol and port. Ping uses ICMP, HTTPS normally uses TCP 443 and DNS can use UDP or TCP 53.
7. Look for the implicit deny. Add only the explicit permits required by the policy.
8. Inspect counters. Generate test traffic and identify which line increases.
9. Test the reverse path. A separate ACL may be blocking replies.
10. Review logs carefully. The log keyword helps identify denied traffic but can create extra CPU and logging load on busy devices.

For a broader diagnostic process, use this layer-by-layer network troubleshooting guide.

A common mistake is testing HTTPS with ping. An ACL may permit TCP port 443 while denying ICMP, so the website can work even when ping fails. Always test the actual application named in the requirement.

What Are the Main Cisco ACL Configuration Best Practices?

Place specific entries before broad entries, use meaningful names and document the purpose of important rules. Always verify the routing path and preserve required management access before applying an ACL remotely.

Recommended practices include:

• Build and review the ACL before applying it.
• Use sequence gaps such as 10, 20 and 30 for later additions.
• Place frequently matched entries near the top when policy order permits.
• Use remark statements to document policy sections.
• Avoid unnecessary permit ip any any statements when the security policy requires default denial.
• Apply the ACL during a controlled lab or maintenance window.
• Save the configuration only after successful testing.
• Keep console access available when testing rules that could block SSH.

A remark can be added as follows:

R1(config)# ip access-list extended USER-TO-SERVERS
R1(config-ext-nacl)# 5 remark Permit approved application services

Summary

Cisco ACL configuration depends on correct matching, rule order, interface placement and direction. Standard ACLs match source addresses, extended ACLs provide protocol and port control, and named ACLs make policies easier to read and edit.

Remember the processing sequence: top to bottom, first match wins and an implicit deny exists at the end. Use show access-lists and show ip interface to confirm both rule matches and interface application.

Frequently Asked Questions

Where should a standard ACL be placed?

A standard ACL should usually be placed close to the destination. Because it checks only the source address, placing it near the source may unintentionally block that source from reaching several valid destinations.

Where should an extended ACL be placed?

An extended ACL should usually be placed close to the source. Its destination, protocol and port matching can stop unwanted traffic before it consumes bandwidth across the network.

What is the implicit deny in a Cisco ACL?

The implicit deny is an invisible deny statement at the end of every ACL. Any packet that reaches the end without matching a permit statement is dropped.

Can standard and extended ACLs use names?

Yes. Cisco IOS supports named standard and named extended ACLs. The name improves readability, while the selected ACL type determines which packet fields can be matched.

Does an ACL take effect immediately after creation?

No. An ACL starts filtering interface traffic only after it is applied with the ip access-group command. It may also be used by another feature, such as NAT or management access control.

How do I remove an ACL from an interface without deleting it?

Enter interface configuration mode and use no ip access-group ACL_NAME in or no ip access-group ACL_NAME out, matching the configured direction. This detaches the ACL but leaves its entries in the running configuration.

To practise these commands in guided router labs, review the CCNA course and enquire about current batch details.

Reviewed by Network Rhinos networking trainers.