CCNA online course

CCNA Extended Access Control Lists (ACLs)

Learn how Cisco IOS IPv4 extended ACLs filter traffic by protocol, addresses, ports, ICMP types, direction, and interface, with configuration, verification, and troubleshooting examples.

An IPv4 Access Control List (ACL) is an ordered collection of Access Control Entries (ACEs). Each ACE describes traffic to permit or deny. A router or multilayer switch evaluates packets against the ACL and takes the action specified by the first matching entry.

An extended ACL provides granular filtering. It can match the IP protocol, source and destination IPv4 addresses, TCP or UDP ports, and selected packet attributes such as ICMP type, TCP flags, DSCP, time ranges, or fragments. This makes extended ACLs useful for segmentation, application restrictions, management-plane filtering, and traffic control between networks.

Purpose and Role of Extended ACLs

ACLs are packet filters, not complete security systems. A traditional IOS ACL normally makes an independent decision for each packet. It does not automatically remember that a packet belongs to an established application session.

• Segmentation: restrict which networks can communicate.
• Application control: permit web, DNS, SSH, or custom application traffic while denying other services.
• Management protection: restrict device administration to an approved subnet.
• Transit filtering: control traffic moving between internal, server, and external networks.

Extended ACLs are more specific than standard ACLs because standard ACLs primarily match a source IPv4 address.

Every ACL has an invisible implicit deny at the end. If a packet does not match any explicit entry, it is denied. Therefore, a policy that blocks only selected traffic usually needs a final permit ip any any, while a default-deny policy may intentionally rely on the implicit deny after specific permits.

What an Extended ACL Can Match

The general extended ACL structure is:

access-list number {permit|deny} protocol source source-wildcard [source-port-condition] destination destination-wildcard [destination-port-condition] [options]

Protocols and Packet Fields

The protocol keyword must agree with the traffic being matched. A TCP rule does not match UDP, and a UDP rule does not match TCP. The keyword ip matches IPv4 traffic broadly, including TCP, UDP, and ICMP, so use it carefully in deny entries.

• tcp permits matching TCP ports and some TCP flags.
• udp permits matching UDP ports.
• icmp permits matching ICMP message types and, on supported platforms, codes.
• ip matches all IPv4 protocols for which the ACL syntax applies.
• A numeric IP protocol value can be used where IOS supports numeric protocol matching.

Wildcard Masks

A wildcard mask tells IOS which address bits must match. A zero bit means “match this bit exactly.” A one bit means “ignore this bit; it may vary.” This is the inverse behavior of a subnet mask.

For a conventional contiguous subnet, calculate the wildcard by subtracting each subnet-mask octet from 255. For example, subnet mask 255.255.255.0 becomes wildcard mask 0.0.0.255.

Noncontiguous wildcard masks, such as 0.0.5.255, can match selected address bits rather than one ordinary subnet. They are difficult to read and easy to misapply. Use them only when the platform supports the syntax and the bit-level policy has been carefully validated.

Numbered and Named Extended ACLs

Traditional numbered IPv4 extended ACLs use the ranges 100–199 and 2000–2699. A numbered ACL is entered one ACE at a time from global configuration mode:

access-list 101 permit tcp 192.0.2.0 0.0.0.255 host 198.51.100.10 eq 443
access-list 101 deny ip 192.0.2.0 0.0.0.255 host 198.51.100.10 log
access-list 101 permit ip any any

A named extended ACL uses a descriptive name and a dedicated configuration mode. Names make policy intent easier to recognize and normally support sequence-number editing:

ip access-list extended USER-TO-WEB
 10 permit tcp 192.0.2.0 0.0.0.255 host 198.51.100.10 eq 80
 20 permit tcp 192.0.2.0 0.0.0.255 host 198.51.100.10 eq 443
 30 deny ip 192.0.2.0 0.0.0.255 host 198.51.100.10 log
 40 permit ip any any

IOS versions and platforms differ in the exact editing features available. Named ACLs with sequence numbers are generally easier to maintain because an ACE can be inserted, replaced, or removed without rebuilding the entire list.

Rule Processing and Ordering

ACL processing is top-down and first-match:

1. IOS compares the packet with the first ACE.
2. If all conditions match, IOS permits or denies the packet and stops processing.
3. If the ACE does not match, IOS checks the next ACE.
4. If no ACE matches, the implicit deny drops the packet.

Specific exceptions must come before broad rules. In the following example, the first entry permits HTTPS, the second denies other traffic to the server, and the third permits unrelated traffic:

10 permit tcp 192.0.2.0 0.0.0.255 host 198.51.100.10 eq 443
20 deny ip 192.0.2.0 0.0.0.255 host 198.51.100.10 log
30 permit ip any any

Moving entry 20 above entry 10 would block HTTPS before the permit can be considered. An explicit deny is useful when you need an intentional boundary or logging. The implicit deny is unavoidable and does not normally provide the same targeted visibility.

Sequence numbers identify ACE positions. On supported IOS releases, entries can be removed or added directly:

ip access-list extended USER-TO-WEB
 no 30
 25 permit tcp 192.0.2.25 0.0.0.0 host 198.51.100.10 eq 443

Rule order also affects return traffic. A forward-direction permit does not automatically create a reverse-direction permit unless the return packet independently matches an ACE or a stateful feature is used.

Port Operators and Transport Filtering

Port conditions apply after specifying tcp or udp. A source-port condition describes the sender’s port; a destination-port condition describes the service being contacted.

IOS often accepts service names such as www, https, domain, and ssh, but numeric ports make documentation and portability clearer. DNS commonly requires both UDP 53 and TCP 53. DHCP requires careful attention to both port directions, especially when filtering relay or client traffic.

ip access-list extended APPLICATION-PORTS
 10 permit tcp 192.0.2.0 0.0.0.255 host 198.51.100.20 range 8000 8010
 20 deny ip any any

ICMP Filtering

ICMP has message types and codes rather than TCP or UDP ports. Useful types include echo, echo-reply, unreachable, and time-exceeded. Codes provide more detail for some message types where IOS supports them.

ip access-list extended ICMP-POLICY
 10 permit icmp 192.0.2.0 0.0.0.255 198.51.100.0 0.0.0.255 echo
 20 permit icmp 198.51.100.0 0.0.0.255 192.0.2.0 0.0.0.255 echo-reply
 30 deny ip any any

Do not automatically block every ICMP message. Excessive ICMP filtering can break diagnostics, traceroute behavior, and Path MTU Discovery. Permit only the operational messages required by the design, but assess the effect of denying error messages before deployment.

Placement and Direction

An inbound ACL is evaluated as a packet enters an interface, before forwarding. An outbound ACL is evaluated after routing selects the exit interface and before the packet is transmitted.

The general design rule is to place an extended ACL close to the traffic source. This prevents unwanted traffic from crossing additional network infrastructure. However, shared egress policies, asymmetric paths, management-plane protection, and router resource constraints can justify another location.

ACLs can be attached to routed physical interfaces, SVIs, routed switch ports, tunnel interfaces, and other supported Layer 3 contexts. VTY login restrictions use an access class rather than an interface transit ACL. Control-plane protection may require a platform-specific control-plane policy.

One ACL can be applied per interface, per protocol family, per direction. The same ACL can be reused on multiple compatible interfaces, but changing a shared ACL changes policy everywhere it is attached. IPv4 and IPv6 filtering are separate policies.

Cisco IOS Configuration Workflow

1. Document requirements: identify sources, destinations, protocols, ports, direction, exceptions, and permitted return traffic.
2. Choose placement: select an interface and direction based on the packet path.
3. Create specific permits: allow only required flows.
4. Add intentional denies: use explicit denies when a prohibited relationship must be visible or logged.
5. Add a final permit when appropriate: use it when the ACL should block only selected traffic and allow other IPv4 traffic.
6. Apply the ACL: attach it with the correct direction.
7. Save, verify, and test: inspect the configuration and test both allowed and denied traffic.

access-list 101 permit tcp 192.0.2.0 0.0.0.255 host 198.51.100.10 eq 443
access-list 101 deny ip 192.0.2.0 0.0.0.255 host 198.51.100.10 log
access-list 101 permit ip any any
interface GigabitEthernet0/0
 ip access-group 101 in
end
copy running-config startup-config

This policy lets the user subnet reach the server on HTTPS, denies other IPv4 traffic from that subnet to that server, and permits other IPv4 traffic. Remove the final permit if the intended policy is default deny.

Return Traffic and Stateless Limitations

Traditional extended ACLs are generally stateless. If internal clients initiate TCP sessions toward an external service, reply packets must also pass an ACL in the reverse direction.

The TCP keyword established is a limited shortcut. It matches TCP packets with the ACK or RST flag set, which often identifies return traffic:

access-list 110 permit tcp any 192.0.2.0 0.0.0.255 established

This does not track sessions, validate sequence state, or distinguish a legitimate reply from every unwanted packet carrying ACK or RST. It does not solve UDP return traffic and does not provide general ICMP state tracking. Use explicit reply rules or a stateful firewall feature when session awareness is required. Dedicated firewalls, zone-based firewalls, and control-plane protection provide capabilities beyond a basic transit ACL.

Verification, Monitoring, and Maintenance

Use show commands to inspect definitions, counters, sequence numbers, and attachment points:

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

• Test from an allowed endpoint and confirm the expected permit counter increases.
• Test from a denied endpoint and confirm the intended deny counter or log appears.
• Check both directions and every routed hop on the forward and return paths.
• Use logging on targeted deny entries rather than high-volume permits whenever possible.
• Document the policy intent, interface, direction, expected flows, owner, and change date.

ACL match counters are operational evidence, not permanent statistics. Clearing counters resets visibility and can affect ongoing monitoring. Use counter-clearing commands only during a controlled test or maintenance window, and record the time of the reset.

Editing and Removing ACLs

Named ACL entries can commonly be removed by sequence number:

ip access-list extended USER-TO-WEB
 no 30

Numbered ACL editing varies by IOS release. Some releases support sequence-based editing, while others make insertion and deletion less convenient. Confirm the available syntax on the device before changing a production list.

When deleting or replacing an ACL, detach it from interfaces first when required by the platform:

interface GigabitEthernet0/0
 no ip access-group USER-TO-WEB in
no ip access-list extended USER-TO-WEB

Check whether the ACL is shared. Removing or modifying a shared ACL can interrupt multiple interfaces or traffic paths.

Practical Policy Examples

Web Access to One Server

Permit users to reach one server on HTTP and HTTPS, deny other traffic to that server, and allow unrelated traffic:

ip access-list extended USER-TO-WEB
 10 permit tcp 192.0.2.0 0.0.0.255 host 198.51.100.10 eq 80
 20 permit tcp 192.0.2.0 0.0.0.255 host 198.51.100.10 eq 443
 30 deny ip 192.0.2.0 0.0.0.255 host 198.51.100.10 log
 40 permit ip any any
interface GigabitEthernet0/0
 ip access-group USER-TO-WEB in

Approved DNS Resolvers

Permit clients to query only approved resolvers. Use separate TCP and UDP entries because they are different protocols:

ip access-list extended CLIENT-DNS
 10 permit udp 192.0.2.0 0.0.0.255 host 198.51.100.53 eq 53
 20 permit tcp 192.0.2.0 0.0.0.255 host 198.51.100.53 eq 53
 30 deny udp 192.0.2.0 0.0.0.255 any eq 53 log
 40 deny tcp 192.0.2.0 0.0.0.255 any eq 53 log
 50 permit ip any any

Restrict Device Administration

Permit SSH from an administration subnet and deny Telnet. A VTY access-class controls who may log in to the device; it is distinct from an interface ACL that filters transit packets:

ip access-list standard VTY-ADMINS
 10 permit 192.0.2.128 0.0.0.31
line vty 0 4
 access-class VTY-ADMINS in
 transport input ssh

For broader IOS security configuration, see configuring passwords in IOS.

Selected ICMP Diagnostics

ip access-list extended ICMP-POLICY
 10 permit icmp 192.0.2.0 0.0.0.255 198.51.100.0 0.0.0.255 echo
 20 permit icmp 198.51.100.0 0.0.0.255 192.0.2.0 0.0.0.255 echo-reply
 30 permit icmp any any unreachable
 40 permit icmp any any time-exceeded
 50 deny ip any any

Troubleshooting Extended ACLs

Design and Exam-Relevant Notes

• Extended ACLs normally go close to the source; standard ACLs are commonly placed close to the destination.
• ACLs use first-match processing. A later permit cannot override an earlier deny.
• The implicit deny exists even when it is not displayed.
• eq 443 after a TCP destination identifies HTTPS by destination port; it does not match arbitrary source-port 443 traffic.
• TCP and UDP require separate ACEs.
• ICMP has message types, not ports.
• established is not a stateful firewall and applies only as a limited TCP flag test.
• A final permit ip any any changes a targeted filter into a selective restriction rather than a default-deny policy.
• Use least privilege, document every permit, and avoid broad any any rules unless their effect is deliberate.
• Management access, routing and control traffic, infrastructure services, and IPv6 policy must be evaluated separately.

Before deployment, confirm the packet path, write the policy in plain language, order specific rules before general rules, verify return traffic, test permitted and denied cases, and save the configuration only after validation.

Related CCNA Topics

• Configure Router on a Stick for VLAN-to-VLAN routing and ACL placement on a routed subinterface.
• Configure Trunk Ports for understanding how VLAN traffic reaches multilayer routing points.
• Configure OSPF when verifying that routing determines the interface through which ACL traffic travels.
• Computer network fundamentals for packet forwarding and protocol concepts.