SkarpChapter 20 of 27
Access Control Lists (ACLs) for Traffic Filtering and Device Access
Shape and secure traffic flows using ACLs to permit or deny packets based on IP, protocol, and port criteria at key points in the network.
ACLs in Context: What They Are and Why They Matter
Why ACLs Matter
You already secured device access with SSH and passwords. ACLs are the next step: they control which actual packets are allowed or blocked as they cross the network.
Canonical Definition
An Access Control List (ACL) is an ordered set of permit and deny statements that control which packets are allowed or blocked based on criteria such as source, destination, and protocol.
Key Ideas Inside the Definition
Three core ideas: ACLs are ordered (top to bottom), each line permits or denies, and matching is based on fields like IP addresses, protocol, and ports.
Where ACLs Are Used
Common uses: filter traffic through a router, protect traffic to the router, and support features like NAT and QoS classification using the same matching logic.
ACLs vs Firewalls
ACLs are simple, packet-by-packet filters. They are not stateful firewalls and do not automatically track TCP sessions unless combined with additional features.
Standard vs Extended ACLs: Concepts and Use Cases
Standard ACLs
Standard ACLs match only on source IPv4 address. They cannot match destination, protocol, or port. They are simple and often used to control who can reach the router.
Standard ACL Ranges
Classic numeric ranges for standard ACLs are 1–99 and 1300–1999. Named ACLs can also be standard, depending on how they are defined.
Extended ACLs
Extended ACLs match on source and destination IP, protocol (IP, TCP, UDP, ICMP, etc.), and TCP/UDP ports. They provide fine-grained control.
Extended ACL Ranges
Classic numeric ranges for extended ACLs are 100–199 and 2000–2699, plus named ACLs that act as extended ACLs.
Choosing the ACL Type
If you only care about who (source), use standard. If you care about who, to where, and which application (port), use extended.
How ACLs Are Processed: Order, Implicit Deny, and Logic
Top-Down Processing
ACLs are evaluated from the top line to the bottom. The first line that matches a packet decides the fate of that packet; the router then stops checking.
Implicit Deny All
Every ACL has an invisible `deny any` at the end. If a packet does not match any explicit line, it is dropped by this implicit deny.
Permit vs Deny
`permit` allows the packet to continue; `deny` drops it. You can optionally add `log` to a line to generate syslog entries for matches.
Simple Matching Example
With `access-list 10 permit 192.168.10.0 0.0.0.255` only that subnet is allowed. All other sources are blocked by the implicit deny.
Common Exam Trap
A broad deny at the top can shadow all later permits. Also, ACLs with only permit lines still block everything else by implicit deny.
ACL Placement Best Practices: To the Device vs Through the Device
Inbound vs Outbound
Inbound ACLs filter traffic as it enters an interface; outbound ACLs filter traffic as it leaves. Use `ip access-group <acl> in|out` on Layer 3 interfaces.
To the Device
ACLs "to the device" protect the router or switch itself, often via `access-class` on VTY lines or ACLs on management interfaces.
Through the Device
ACLs "through the device" filter transit traffic routed between networks. They are applied to Layer 3 interfaces with `ip access-group`.
Placement for Extended ACLs
Best practice: place extended ACLs close to the source of the traffic you want to control, to drop unwanted packets as early as possible.
Placement for Standard ACLs
Best practice: place standard ACLs close to the destination, because they only look at the source and can otherwise over-block traffic.
Configuring a Basic Standard ACL for Device Management
Scenario Overview
R1 has an admin subnet 10.10.10.0/24 and a user subnet 10.20.20.0/24. Only the admin subnet should be able to SSH to R1.
Create Standard ACL 10
Configure: `access-list 10 permit 10.10.10.0 0.0.0.255`. This permits any host in 10.10.10.0/24; everything else is implicitly denied.
Apply ACL to VTY Lines
Under `line vty 0 4`, use `access-class 10 in` and `transport input ssh`. This restricts inbound SSH/Telnet based on ACL 10.
Verify Behavior
SSH from 10.10.10.x should succeed; SSH from 10.20.20.x should fail. Use `show access-lists 10` to see match counters.
Key Takeaway
Standard ACLs plus `access-class` are ideal to control who can manage the device, because you only need to filter based on source IP.
Configuring an Extended ACL for Traffic Filtering Through a Router
Scenario Overview
LAN1 clients (192.168.1.0/24) access a web server 192.168.2.100 via R1. Only HTTP (TCP/80) from LAN1 to that server should be allowed.
Placement Decision
Because this is an extended ACL, best practice is to place it close to the source: on R1’s G0/0 (LAN1 side), inbound.
Create Extended ACL 101
Command: `access-list 101 permit tcp 192.168.1.0 0.0.0.255 host 192.168.2.100 eq 80`. This allows only HTTP from LAN1 to the server.
Apply ACL to Interface
Under `interface g0/0`, use `ip access-group 101 in` to filter traffic entering from LAN1 toward the rest of the network.
Verify Behavior
HTTP from LAN1 to 192.168.2.100 works; pings/SSH do not. Traffic to other servers is denied because only that specific flow is permitted.
Thought Exercise: Predict ACL Behavior and Placement
Work through these scenarios mentally (or jot answers), then check yourself against the hints.
Scenario 1: Standard vs Extended
You manage a router that connects three VLANs:
- VLAN10: Staff (10.10.10.0/24)
- VLAN20: Students (10.20.20.0/24)
- VLAN30: Servers (10.30.30.0/24) including a shared file server 10.30.30.50
Requirement: Students should not be able to access the file server at all. Staff should have full access.
Questions:
- Do you need a standard or extended ACL to meet this requirement?
- On which interface and direction would you apply it, following best practices?
Think before reading hints.
Hints:
- You care about who (Students) and what (file server destination), so you need to match both source and destination.
- Where is the source of the unwanted traffic?
Scenario 2: To the device
Same topology. Requirement: Only Staff subnet should be allowed to SSH into the router for management.
Questions:
- Do you need a standard or extended ACL?
- Do you apply it to an interface with `ip access-group` or to VTY lines with `access-class`?
Hints:
- You only care about the source of management connections.
- Think of the earlier example with ACL 10 and `access-class in`.
Use this to test whether you can choose ACL type and placement from a description, which is exactly how CCNA questions are phrased.
Quiz 1: Core ACL Concepts
Answer this question to check your understanding of ACL logic and placement.
You configure the following on a router: access-list 15 permit 192.168.50.0 0.0.0.255 ! interface g0/0 ip access-group 15 in What happens to traffic entering interface g0/0 from source 192.168.60.10?
- It is permitted because there is no explicit deny in ACL 15.
- It is denied because it does not match the permit statement and hits the implicit deny.
- It is permitted because standard ACLs only filter traffic to the router, not through it.
- It is denied only if it is destined for the router itself, but forwarded if it is transit traffic.
Show Answer
Answer: B) It is denied because it does not match the permit statement and hits the implicit deny.
Standard ACL 15 has a single permit for 192.168.50.0/24. Traffic from 192.168.60.10 does not match that line, so it matches no explicit statement and is dropped by the implicit deny at the end. Applying the ACL inbound on g0/0 with `ip access-group 15 in` affects all traffic entering that interface, regardless of destination.
Quiz 2: Standard vs Extended and Placement
Apply what you learned about ACL types and best-practice placement.
You must allow only HTTP and HTTPS from subnet 10.1.1.0/24 to server 172.16.0.10, and block all other traffic from that subnet to that server. Following best practices, what is the BEST approach?
- Create a standard ACL permitting 10.1.1.0/24 and apply it outbound on the server-facing interface.
- Create an extended ACL permitting TCP from 10.1.1.0/24 to 172.16.0.10 eq 80 and 443, and apply it inbound on the 10.1.1.0/24-facing interface.
- Create an extended ACL denying TCP from 10.1.1.0/24 to 172.16.0.10 eq 80 and 443, and apply it close to the server.
- Create a standard ACL denying 10.1.1.0/24 and apply it inbound on the server-facing interface.
Show Answer
Answer: B) Create an extended ACL permitting TCP from 10.1.1.0/24 to 172.16.0.10 eq 80 and 443, and apply it inbound on the 10.1.1.0/24-facing interface.
You need to match both source, destination, and ports, so you need an extended ACL. Best practice is to place extended ACLs close to the source, so apply it inbound on the interface facing 10.1.1.0/24. The ACL should permit only TCP to destination 172.16.0.10 on ports 80 and 443; all other traffic from that subnet to that server is denied implicitly.
Hands-On: Building and Verifying ACLs (Command Reference)
Use this step as a mini reference for core ACL commands you will see in labs and on the exam.
1. Standard numbered ACL (IPv4)
```plaintext
! Permit a single host
access-list 10 permit 192.168.1.10
! Permit a subnet
access-list 10 permit 192.168.1.0 0.0.0.255
! Explicitly deny another subnet (optional, implicit deny still exists)
access-list 10 deny 192.168.2.0 0.0.0.255
! Apply to interface
interface g0/0
ip access-group 10 in
```
2. Extended numbered ACL (IPv4)
```plaintext
! Allow HTTP and HTTPS from 10.0.0.0/24 to 172.16.0.10
access-list 101 permit tcp 10.0.0.0 0.0.0.255 host 172.16.0.10 eq 80
access-list 101 permit tcp 10.0.0.0 0.0.0.255 host 172.16.0.10 eq 443
! Optional: log all other attempts to that server
access-list 101 deny ip any host 172.16.0.10 log
interface g0/1
ip access-group 101 in
```
3. Named ACLs (recommended in modern IOS)
```plaintext
! Named standard ACL
ip access-list standard MGMT_ONLY
permit 10.10.10.0 0.0.0.255
! Named extended ACL
ip access-list extended WEB_FILTER
permit tcp 10.0.0.0 0.0.0.255 host 172.16.0.10 eq 80
deny ip any any log
! Apply named ACL
interface g0/0
ip access-group WEB_FILTER in
```
4. Device management protection
```plaintext
! Allow only 10.10.10.0/24 to manage the router via VTY
access-list 20 permit 10.10.10.0 0.0.0.255
line vty 0 4
access-class 20 in
transport input ssh
login local
```
5. Verification commands
```plaintext
show access-lists ! View all ACLs and hit counts
show ip interface g0/0 ! See which ACLs are applied in/out
show running-config | sec access-list
```
Practice: Copy one of these examples and adapt the addresses and interfaces to your own lab topology.
Flashcards: Key ACL Terms and Rules
Use these flashcards to reinforce core ACL concepts and exam language.
- Canonical ACL definition (exact wording)
- An Access Control List (ACL) is an ordered set of permit and deny statements that control which packets are allowed or blocked based on criteria such as source, destination, and protocol.
- Standard ACL (concept)
- A standard ACL matches only on source IPv4 address. It cannot specify destination, protocol, or port, and is often used for simple filtering and device management access control.
- Extended ACL (concept)
- An extended ACL can match on source and destination IP addresses, protocol (IP, TCP, UDP, ICMP, etc.), and TCP/UDP ports, allowing fine-grained traffic control.
- Implicit deny
- Every ACL ends with an implicit "deny any" (for IP ACLs) that is not shown in the configuration. Any packet that does not match a permit or deny line is dropped by this implicit rule.
- ACL processing rule
- ACLs are processed top to bottom, first match wins. As soon as a packet matches a line, the corresponding permit or deny is applied and no further lines are checked.
- Best placement: extended ACLs
- Place extended ACLs close to the source of the traffic you want to control, to drop unwanted packets as early as possible.
- Best placement: standard ACLs
- Place standard ACLs close to the destination, because they only match on source and can otherwise over-block traffic.
- Inbound vs outbound ACL direction
- Inbound ACLs filter packets as they enter an interface, before routing. Outbound ACLs filter packets as they leave an interface, after routing.
- Command to apply an ACL to an interface
- Use `ip access-group <acl-name-or-number> in|out` under the interface configuration mode to apply an IPv4 ACL in a specific direction.
- Command to restrict VTY access with an ACL
- Under `line vty` configuration, use `access-class <acl-number-or-name> in` to control which source IPs can open management sessions (Telnet/SSH) to the device.
Key Terms
- ACL
- An Access Control List (ACL) is an ordered set of permit and deny statements that control which packets are allowed or blocked based on criteria such as source, destination, and protocol.
- Named ACL
- An ACL identified by a name instead of a number, created with `ip access-list standard|extended <name>`, allowing easier editing and management.
- Inbound ACL
- An ACL applied in the 'in' direction on an interface, filtering packets as they enter that interface.
- Extended ACL
- An IPv4 ACL type that can match on source and destination IP addresses, protocol, and TCP/UDP ports for granular traffic control.
- Outbound ACL
- An ACL applied in the 'out' direction on an interface, filtering packets as they leave that interface.
- Standard ACL
- An IPv4 ACL type that matches only on source IP address, used for simple filtering and device management control.
- access-class
- Cisco IOS line command used to apply an ACL to VTY lines to control which IP addresses can establish management sessions to the device.
- Implicit deny
- The invisible final rule in every ACL that denies all traffic not explicitly permitted or denied by earlier lines.
- Wildcard mask
- A mask used in ACLs where 0 bits must match exactly and 1 bits can vary, often the inverse of a subnet mask.
- ip access-group
- Cisco IOS interface command used to apply an IPv4 ACL to an interface in a specified direction (in or out).