Access Control Lists (ACLs) 3.0

Access Control Lists filter, classify, permit, or deny traffic by examining packet fields. At the CCNA level, the core skills are:

• distinguishing standard, extended, numbered, and named ACLs
• reading ACL entries from left to right
• calculating wildcard masks
• placing ACLs on the correct interface and in the correct direction
• understanding first-match processing and the implicit deny
• safely revising ACL entries with sequence numbers
• verifying and troubleshooting the result

This guide is organized in two parts: Core ACL concepts and configuration and Expanded examples, labs, editing, and troubleshooting.

1. What an ACL does

An Access Control List is an ordered list of rules. Each individual permit or deny rule is an Access Control Entry (ACE).

ACLs can:

• permit or deny transit traffic
• restrict management access to a router or switch
• identify traffic for NAT
• identify interesting traffic for VPN encryption
• classify traffic for QoS
• match routes used by route maps and redistribution policies

An ACL is not automatically active when it is created. The normal workflow is:

1. Create the ACL.
2. Apply it to an interface or management line.
3. Specify the direction in which it should be evaluated.

Without an ACL applied, the interface does not perform ACL filtering.

2. How ACL processing works

ACLs are evaluated from top to bottom.

1. The device compares the packet against the first ACE.
2. If the packet matches, the listed action is taken.
3. Processing stops immediately after the first match.
4. If the packet does not match, the next ACE is checked.
5. If no ACE matches, the packet reaches the implicit deny and is dropped.

Every ACL ends with an invisible deny statement:

deny any

Or conceptually for an extended ACL:

deny ip any any

Because of this implicit deny, an ACL should normally contain at least one permit entry. An ACL containing only deny entries blocks everything else that reaches it.

No ACL versus an ACL with no match

3. Standard, extended, numbered, and named ACLs

Standard ACLs

Standard ACLs match only the source IPv4 address.

They cannot directly match:

• destination IP addresses
• TCP or UDP
• application ports
• specific upper-layer protocols

access-list 10 deny host 10.10.10.50
access-list 10 permit 10.10.10.0 0.0.0.255

Extended ACLs

Extended ACLs can match:

• protocol
• source address
• destination address
• source port
• destination port

access-list 100 deny tcp 10.10.30.0 0.0.0.255 host 10.10.20.1 eq 23
access-list 100 permit ip any any

Named ACLs

Named ACLs use a descriptive label instead of relying only on a number.

ip access-list extended BLOCK-TELNET
 deny tcp 10.10.30.0 0.0.0.255 host 10.10.20.1 eq 23
 permit ip any any

Named ACLs are easier to identify and easier to revise with sequence numbers.

4. Reading an extended ACL from left to right

Consider:

access-list 100 deny tcp 10.10.30.0 0.0.0.255 gt 49151 host 10.10.20.1 eq 23

A more common ACL would omit the source-port condition and filter only the destination port:

access-list 100 deny tcp 10.10.30.0 0.0.0.255 host 10.10.20.1 eq 23

Common protocol keywords

Depending on IOS context-sensitive help, an extended ACL may offer protocol choices such as:

• ip
• tcp
• udp
• icmp
• ospf
• eigrp
• gre
• esp
• ahp

Use ip when the ACE should match any IPv4 protocol.

Use tcp or udp when the ACE needs to match transport-layer ports.

Common port operators

deny tcp any any eq 23
permit tcp any host 192.0.2.10 eq 443
permit udp 10.1.0.0 0.0.255.255 any eq 53
deny tcp any any range 20 21

5. Wildcard masks

ACLs use wildcard masks rather than subnet masks.

A wildcard mask tells IOS which address bits must match.

• 0 means compare this bit.
• 1 means ignore this bit.

For normal contiguous subnet masks:

wildcard mask = 255.255.255.255 − subnet mask

Common wildcard masks

host and any

These are shorthand keywords.

host 10.1.1.10
! equivalent to:
10.1.1.10 0.0.0.0

any
! equivalent to:
0.0.0.0 255.255.255.255

Matching several contiguous subnets

To match 10.1.0.0 through 10.1.3.255:

10.1.0.0 0.0.3.255

This wildcard covers four contiguous /24 networks.

Wildcard masks also appear in other IOS features, including OSPF network statements.

6. Placement rules

Placement and direction are related, but they are not the same question.

• Placement asks: On which router and interface should the ACL be applied?
• Direction asks: Should packets be evaluated as they enter or leave that interface?

Standard ACL placement

Place a standard ACL close to the destination.

Reason: a standard ACL sees only the source. If it is placed near the source, it may block that source from every destination instead of only the intended target.

Extended ACL placement

Place an extended ACL close to the source.

Reason: an extended ACL can identify the exact source, destination, protocol, and port. Unwanted traffic can be dropped before it consumes bandwidth across the network.

These are strong default rules, not substitutes for reading the actual topology.

The ACL Placement tool should reinforce this process:

1. Identify the source.
2. Identify the destination.
3. Decide whether a standard or extended ACL is required.
4. Choose the nearest safe interface.
5. Determine whether traffic crosses that interface inbound or outbound.

7. Inbound versus outbound

Inbound ACL

An inbound ACL is checked as a packet enters an interface, before the routing decision.

ip access-group 100 in

If the packet is denied, the router does not spend additional effort routing it.

Outbound ACL

An outbound ACL is checked after routing, as the packet is about to leave an interface.

ip access-group 100 out

Packet-path method

Do not guess the direction from the diagram. Trace the packet.

Ask:

• Which interface does the packet enter?
• Which interface does it leave?
• Where is the ACL being placed?
• At that exact interface, is the packet entering or leaving?

Inbound is often more efficient, but correctness comes first.

8. Creating and applying an ACL

Numbered standard ACL

R1(config)#access-list 10 deny host 10.1.1.50
R1(config)#access-list 10 permit 10.1.1.0 0.0.0.255
R1(config)#interface GigabitEthernet0/1
R1(config-if)#ip access-group 10 out

Numbered extended ACL

R1(config)#access-list 100 deny tcp 10.1.1.0 0.0.0.255 host 10.2.2.10 eq 23
R1(config)#access-list 100 permit ip any any
R1(config)#interface GigabitEthernet0/0
R1(config-if)#ip access-group 100 in

Named standard ACL

R1(config)#ip access-list standard MGMT-SOURCES
R1(config-std-nacl)#10 permit host 10.10.10.10
R1(config-std-nacl)#20 deny any log

Named extended ACL

R1(config)#ip access-list extended BLOCK-TELNET
R1(config-ext-nacl)#10 deny tcp 10.10.30.0 0.0.0.255 host 10.10.20.1 eq 23
R1(config-ext-nacl)#20 permit ip any any
R1(config)#interface GigabitEthernet0/0
R1(config-if)#ip access-group BLOCK-TELNET in

Interface limits

For IPv4 ACLs, an interface can have:

• one inbound ACL
• one outbound ACL

Applying another ACL in the same direction replaces the previous assignment for that protocol and direction.

9. Restricting VTY management access

Interface filtering uses ip access-group.

VTY management-line filtering uses access-class.

Example: permit SSH only from one administrator workstation.

R1(config)#access-list 5 permit host 10.0.0.10
R1(config)#line vty 0 15
R1(config-line)#access-class 5 in
R1(config-line)#transport input ssh
R1(config-line)#login local

A standard ACL is often appropriate here because the question is simply which source addresses may manage the device.

10. Rule order

A broad entry placed too early can make later entries unreachable.

access-list 10 deny host 172.18.18.50
access-list 10 permit 172.18.18.0 0.0.0.255

access-list 10 permit 172.18.18.0 0.0.0.255
access-list 10 deny host 172.18.18.50

The host is already included in the subnet permit, so the later deny is never reached. The same issue occurs with permit any and deny any.

11. Logging matches

The log keyword can be appended to an ACE.

access-list 10 deny any log
access-list 100 deny tcp any any eq 23 log

An explicit final deny with logging makes the otherwise invisible implicit-deny behavior observable. Use logging carefully in production because heavily matched ACEs can generate substantial messages.

12. Why standard ACLs cannot solve every problem

Objective: Block traffic sourced from 3.3.3.0/24 only when it is going to 11.11.11.0/24.

A standard ACL can match the source:

access-list 1 deny 3.3.3.0 0.0.0.255
access-list 1 permit any

But it cannot identify the destination. Applied at the wrong location, this blocks traffic from 3.3.3.0/24 to every destination.

An extended ACL is required:

access-list 100 deny ip 3.3.3.0 0.0.0.255 11.11.11.0 0.0.0.255
access-list 100 permit ip any any

• Standard ACL: source only.
• Extended ACL: source plus destination, and optionally protocol and port.

13. Host and any examples

Block one source host from one destination host

access-list 101 deny ip host 172.12.123.3 host 1.1.1.1
access-list 101 permit ip any any

Permit traffic from any source to one server

access-list 101 permit ip any host 172.12.123.1
access-list 101 permit ip any any

The second line permits other traffic that would otherwise be caught by the implicit deny.

14. TCP and UDP examples

Block Telnet, permit other IPv4 traffic

access-list 100 deny tcp any any eq 23
access-list 100 permit ip any any

Permit HTTPS to one server

access-list 110 permit tcp any host 192.168.20.10 eq 443
access-list 110 deny ip any any log

Permit DNS queries from one subnet

access-list 120 permit udp 10.10.10.0 0.0.0.255 any eq 53
access-list 120 permit tcp 10.10.10.0 0.0.0.255 any eq 53
access-list 120 deny ip any any log

Permit ICMP echo while denying other ICMP

access-list 130 permit icmp 10.1.1.0 0.0.0.255 host 10.2.2.10 echo
access-list 130 deny icmp any any
access-list 130 permit ip any any

15. Sequence numbers and safe editing

Modern ACL configuration commonly displays sequence numbers in increments of 10:

10 deny host 172.18.18.50
20 permit 172.18.18.0 0.0.0.255
30 deny any log

Why not use consecutive values such as 1, 2, and 3?

Spacing leaves room to insert new entries later.

10 deny host 172.18.18.50
20 permit 172.18.18.0 0.0.0.255

! New deny inserted between them:
15 deny host 172.18.18.60

If the sequence numbers were 1 and 2, there would be no integer available between them. The ACL could still be rebuilt or resequenced, but the edit would be less convenient.

ACL number versus sequence number

Do not confuse these:

ip access-list extended 100
! 100 identifies the ACL

10 deny tcp any any eq 23
20 permit ip any any
! 10 and 20 are sequence numbers inside ACL 100

The same concept applies to named ACLs:

ip access-list extended BLOCK-TELNET
 10 deny tcp any any eq 23
 20 permit ip any any

Why examples may use 10, 20, 30 or 100, 110, 120

Both patterns provide insertion space.

• 10, 20, 30 is compact and common.
• 100, 110, 120 can reserve lower values for future special entries or make policy sections easier to group.
• The key principle is spacing, not one mandatory pattern.

Removing one ACE

R1(config)#ip access-list standard 17
R1(config-std-nacl)#no 30

Inserting a replacement ACE

R1(config-std-nacl)#15 deny 172.19.19.0 0.0.0.255

Complete example

Standard IP access list 17
    10 deny   172.18.18.0, wildcard bits 0.0.0.255
    20 permit any
    30 deny   172.19.19.0, wildcard bits 0.0.0.255

Sequence 30 is unreachable because sequence 20 already permits everything.

R1(config)#ip access-list standard 17
R1(config-std-nacl)#no 30
R1(config-std-nacl)#15 deny 172.19.19.0 0.0.0.255

Standard IP access list 17
    10 deny   172.18.18.0, wildcard bits 0.0.0.255
    15 deny   172.19.19.0, wildcard bits 0.0.0.255
    20 permit any

16. Router-generated traffic caveat

Interface ACL behavior is designed primarily around transit traffic. Traffic generated locally by the router itself may not be tested in the same way as traffic passing through the router. This can confuse lab testing when a ping or Telnet session is initiated from the router CLI.

When validating an interface ACL, test from the actual source host represented in the scenario whenever possible.

17. Verification commands

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

Look for:

• correct ACE order
• expected sequence numbers
• hit counters increasing
• correct interface assignment
• correct inbound or outbound direction
• an explicit permit for desired traffic
• wildcard-mask mistakes
• an ACL assignment that replaced another ACL

18. Troubleshooting workflow

Use this order:

1. Restate the exact desired traffic policy.
2. Identify the source and destination.
3. Identify the protocol and port, if relevant.
4. Decide whether a standard or extended ACL is required.
5. Trace the packet across the topology.
6. Confirm the selected interface.
7. Confirm inbound or outbound direction.
8. Read the ACL top to bottom.
9. Check for an earlier broad match.
10. Check wildcard masks.
11. Check the implicit deny.
12. Confirm the ACL is actually applied.
13. Generate test traffic and inspect hit counters.

Symptom table

19. Packet Tracer lab skeleton

Learning objectives

By the end of the lab, the student should be able to:

• select standard or extended ACLs
• calculate wildcard masks
• place ACLs near the correct source or destination
• choose inbound or outbound direction
• apply numbered and named ACLs
• interpret the implicit deny
• verify ACL hit counters
• insert and remove ACEs using sequence numbers
• repair an ACL with incorrect rule order

Suggested topology

PC-A ---- SW1 ---- R1 ---- R2 ---- SW2 ---- SERVER
                    |
                  PC-B LAN

Suggested devices: 2 routers, 2 access switches, 2 client PCs, and 1 server.

Student tasks

1. Verify full connectivity before applying ACLs.
2. Create a standard ACL that blocks PC-A from the server LAN without blocking PC-A from PC-B.
3. Explain why the standard ACL should be placed near the destination.
4. Create an extended ACL that blocks HTTP from PC-B to the server while allowing HTTPS.
5. Place the extended ACL close to PC-B.
6. Intentionally place permit ip any any before a deny and observe the result.
7. Repair the ACL by inserting the deny before the permit.
8. Add an explicit final deny with logging.
9. Verify interface assignments and hit counters.
10. Remove one ACE without deleting the entire ACL.
11. Save the configuration.

Brief topology guidance

Keep the topology small enough that students can trace every packet path manually. The purpose is not routing complexity. Static routes or a simple routing protocol may be preconfigured so the student can focus on ACL behavior.

The lab should start with working end-to-end connectivity. Any failure after ACL deployment should therefore be attributable to ACL configuration rather than unresolved routing.

20. Integration with CCNA Practice Labs tools

The ACL 3.0 guide links conceptually to three complementary experiences:

21. Exam checklist

• Standard ACLs match source addresses only.
• Extended ACLs can match source, destination, protocol, and port.
• Standard ACLs are generally placed near the destination.
• Extended ACLs are generally placed near the source.
• ACLs are read top to bottom.
• The first match wins.
• Every ACL has an implicit deny.
• A wildcard 0 means match; 1 means ignore.
• /24 uses wildcard 0.0.0.255.
• host means wildcard 0.0.0.0.
• any represents all IPv4 addresses.
• Use ip access-group on interfaces.
• Use access-class on VTY lines.
• One IPv4 ACL may be active per interface, per direction.
• Sequence-number spacing makes later insertion easier.
• no access-list <number> removes the complete numbered ACL.
• Confirm the interface and direction by tracing the packet.
• Test with real source hosts and verify hit counters.

22. Final review questions

1. Why is a standard ACL normally placed near the destination?
2. Why is an extended ACL normally placed near the source?
3. What happens when no ACE matches a packet?
4. What is the difference between ACL number 100 and sequence number 100?
5. Why are ACE sequence numbers commonly spaced by ten?
6. Which command applies an ACL to an interface?
7. Which command restricts sources permitted to access VTY lines?
8. What does 0.0.0.0 mean as a wildcard mask?
9. Why is a deny below permit ip any any unreachable?
10. How would you remove one ACE without deleting the complete ACL?