Cisco & Networking · Lesson 13
Access Control Lists
Learn how Cisco IPv4 ACLs match traffic, how rule order and wildcard masks affect policy, and how to permit required services while blocking only the traffic the scenario actually forbids.
ACL mistakes can look like routing, VLAN, DNS, or application failures. This lesson focuses on reading the packet path and ACL evidence before changing policy.
Lesson Snapshot
Learning objectives
Read policy in packet order
Explain how IPv4 access control lists evaluate traffic from top to bottom.
Distinguish standard and extended ACLs and choose the right type for a requirement.
Use wildcard masks correctly without confusing them with subnet masks.
Place ACLs inbound or outbound based on the traffic path and policy goal.
Inspect ACL entries, hit counters, and interface application before editing policy.
Modify an ACL narrowly while preserving required traffic and verifying the return path.
Core idea
ACL order is part of the policy
Cisco IOS stops at the first matching ACE. A perfectly written deny can do nothing if a broader permit already matched the packet.
Competition warning
Never forget the implicit deny
A short ACL with one permit statement does not mean everything else is allowed. Unmatched traffic reaches the implicit deny.
Core concepts
Six ideas behind IPv4 ACL behavior
Access control list
An ordered set of permit and deny statements that Cisco IOS can use to classify and filter traffic.
Access control entry
One individual rule inside an ACL. Each ACE matches specific traffic and applies a permit or deny action.
Top-down evaluation
Cisco IOS checks entries from the top until the first match is found. Later entries are not evaluated after a match.
Implicit deny
IPv4 ACLs end with an unseen deny any behavior. Traffic not explicitly permitted by any earlier entry is denied.
Direction
An ACL applied inbound filters packets as they enter an interface. An outbound ACL filters packets as they leave an interface.
Wildcard mask
A mask used by Cisco ACLs to describe which address bits must match and which may vary.
Standard vs extended
Choose the ACL type that can express the requirement
What can be matched
Standard
Primarily source IPv4 address.
Extended
Source, destination, protocol, and often TCP/UDP port information.
Typical numbered ranges
Standard
1-99 and 1300-1999 on many IOS versions.
Extended
100-199 and 2000-2699 on many IOS versions.
Placement idea
Standard
Often placed closer to the destination because it cannot distinguish destination or service.
Extended
Often placed closer to the source because it can filter the unwanted flow more precisely.
Best use
Standard
Simple source-based restrictions.
Extended
Detailed traffic policy such as permitting one subnet to reach one server on HTTPS.
Risk if placed poorly
Standard
Can accidentally block a source from reaching many destinations.
Extended
Can still break required traffic if protocol, port, direction, or destination is wrong.
Evaluation process
Follow one packet through the ACL
Packet reaches an ACL-enabled interface
The router identifies whether an inbound or outbound ACL applies at this point in the packet path.
First ACL entry is tested
The packet is compared against the first ACE using source, destination, protocol, and other conditions supported by that ACL type.
No match moves to the next entry
Evaluation continues in order until one statement matches.
First match decides the action
If the matching ACE says permit, processing continues. If it says deny, the packet is discarded by that ACL.
No explicit match reaches implicit deny
Any traffic that reaches the end without matching a permit is denied.
Counters record matching traffic
On supported IOS versions, ACL hit counts can provide evidence about which entries are actually matching packets.
Wildcard masks
Match exactly the addresses the rule intends
| Subnet mask | Wildcard | Meaning |
|---|---|---|
| 255.255.255.255 | 0.0.0.0 | Match one exact IPv4 address. |
| 255.255.255.0 | 0.0.0.255 | Match every address in one /24 network. |
| 255.255.255.192 | 0.0.0.63 | Match one /26 block when paired with the correct network address. |
| 255.255.0.0 | 0.0.255.255 | Match one /16 network. |
| 0.0.0.0 | 255.255.255.255 | Match any IPv4 address. |
Write the subnet mask
Start with the actual subnet mask of the network you want to match.
Subtract each octet from 255
For example, 255 - 255 = 0 and 255 - 192 = 63.
Pair with the network address
A wildcard only makes sense when combined with the correct base address.
Check the range
Confirm the resulting match covers exactly the intended hosts and no broader network.
ACL shortcuts
host and any improve readability
host 192.168.10.25Equivalent: 192.168.10.25 0.0.0.0
Match exactly one IPv4 host.
anyEquivalent: 0.0.0.0 255.255.255.255
Match any IPv4 address.
Cisco inspection
Read both the ACL definition and where it is applied
show access-listsDisplay configured ACLs and, where supported, match counters.
show ip access-listsDisplay IPv4 ACLs in a focused format on supported IOS versions.
show running-config | include access-listFind numbered ACL statements in the running configuration.
show running-config | section ip access-listReview named ACL sections where supported.
show running-config interface <interface>Confirm whether an ACL is applied inbound or outbound on a specific interface.
show ip interface <interface>Review inbound and outbound ACL application information on many IOS platforms.
show ip interface briefConfirm interface state and addresses before reasoning about ACL placement.
show ip routeVerify routing is correct before assuming an ACL is the cause of a traffic failure.
Numbered ACL examples
Read the intent before applying the list
Permit one source subnet with a standard ACL
configure terminalaccess-list 10 permit 192.168.10.0 0.0.0.255endBecause of the implicit deny, other unmatched sources would be denied if this ACL were applied.
Permit Staff HTTPS access to one server
configure terminalaccess-list 110 permit tcp 192.168.10.0 0.0.0.255 host 192.168.30.10 eq 443endThis permits only TCP destination port 443 from the Staff subnet to the selected server.
Permit ICMP for a fictional troubleshooting path
configure terminalaccess-list 110 permit icmp 192.168.10.0 0.0.0.255 192.168.30.0 0.0.0.255endOnly add diagnostic traffic the scenario actually requires.
Named ACLs
Easier to review and edit precisely
Readable purpose
Names such as STAFF_TO_SERVERS can communicate intent better than a number alone.
Sequence numbers
Named ACL editing commonly makes it easier to insert or remove individual entries without rebuilding the entire list.
Targeted maintenance
A single ACE can often be removed by sequence number while leaving the rest of the policy intact.
Better review
Named ACL blocks are easier to compare with scenario requirements during a competition review.
Enter named extended ACL mode
configure terminalip access-list extended STAFF_TO_SERVERSPermit required HTTPS
10 permit tcp 192.168.10.0 0.0.0.255 host 192.168.30.10 eq 443Permit required DNS
20 permit udp 192.168.10.0 0.0.0.255 host 192.168.30.53 eq 5330 permit tcp 192.168.10.0 0.0.0.255 host 192.168.30.53 eq 53Add a deliberate final policy statement if required
90 deny ip 192.168.10.0 0.0.0.255 192.168.30.0 0.0.0.255 logexitendVerify the ACL
show ip access-lists STAFF_TO_SERVERSDirection
Think from the router interface's point of view
PC -> Router interface
Inbound
The packet is entering the router through that interface.
Router -> Server VLAN
Outbound
The packet is leaving the router toward the destination network.
Server reply -> Router
Inbound on the server-facing interface
Return traffic has its own direction relative to each interface.
Router -> PC
Outbound on the PC-facing interface
Always reason from the router interface's point of view, not from the user's.
Placement reasoning
Filter at the point that expresses the policy cleanly
Block one source subnet from reaching many destinations
Standard ACL closer to the destination
A standard ACL cannot distinguish destinations, so placing it too close to the source can block more traffic than intended.
Block Students from SSH to one server but allow HTTPS
Extended ACL closer to the source
Extended matching can identify source, destination, protocol, and port before unwanted traffic crosses more of the network.
Restrict remote management traffic into a router interface
Depends on management design
You must understand whether the ACL protects data-plane forwarding, VTY access, or another management feature before applying it.
Permit only required traffic between two VLANs
Where the rule cleanly sees the source and destination path
Choose a location that enforces the policy without duplicating or bypassing required flows.
Applying ACLs
Definition and interface application are separate steps
Apply an extended ACL inbound on a source VLAN gateway
Commands
configure terminalinterface GigabitEthernet0/0.10ip access-group STAFF_TO_SERVERS inendVerify
show ip interface GigabitEthernet0/0.10Apply a standard ACL outbound toward a destination
Commands
configure terminalinterface GigabitEthernet0/1ip access-group 10 outendVerify
show running-config interface GigabitEthernet0/1Remove one applied ACL without deleting its definition
Commands
configure terminalinterface GigabitEthernet0/1no ip access-group 10 outendVerify
show ip interface GigabitEthernet0/1First-match examples
Ordering can completely change the outcome
Case 1
10 permit ip 192.168.10.0 0.0.0.255 any20 deny tcp 192.168.10.0 0.0.0.255 host 192.168.30.10 eq 22SSH is permitted
The broad permit at sequence 10 matches first, so sequence 20 is never reached.
Case 2
10 deny tcp 192.168.20.0 0.0.0.255 host 192.168.30.10 eq 2220 permit ip 192.168.20.0 0.0.0.255 anySSH to the server is denied while other IP traffic from the subnet can continue.
The specific deny is evaluated before the broader permit.
Case 3
10 permit tcp any host 192.168.30.10 eq 443Only matching HTTPS traffic is permitted by this ACL
Unmatched traffic reaches the implicit deny unless another permit entry is added.
Common service ports
Match the protocol the application actually uses
SSH
TCP · 22
permit tcp <source> host <server> eq 22
HTTP
TCP · 80
permit tcp <source> host <server> eq 80
HTTPS
TCP · 443
permit tcp <source> host <server> eq 443
DNS
UDP/TCP · 53
Often requires separate UDP and TCP permit statements depending on the requirement.
ICMP
ICMP
ICMP does not use TCP or UDP port numbers.
Return traffic
Classic ACL filtering is not automatically stateful
Classic ACLs are generally stateless
A permit in one direction does not automatically create a state table that permits every related return packet.
TCP established keyword exists
Cisco extended ACLs can match certain TCP packets with ACK or RST using the established keyword, but this is not the same as a full stateful firewall.
ICMP behavior needs deliberate rules
Echo requests and replies are separate traffic directions. If the policy filters both directions, both flows may need to be considered.
DNS may use UDP and TCP
A policy that permits only UDP 53 can fail for cases where DNS legitimately uses TCP.
Safe ACL editing
Change one ACE, not the whole policy
Named ACL sequence numbers
Sequence numbers allow targeted insertion and removal of individual ACEs on supported IOS versions.
Numbered ACL caution
Older numbered ACL workflows can be less convenient to edit line by line, so inspect platform capabilities before rebuilding a working list.
Never delete the whole ACL first
Removing a working ACL can temporarily open or close far more traffic than intended.
Change one ACE at a time
Use the smallest supported edit, verify counters and traffic, then continue.
Preserve ordering intent
A correct rule in the wrong position can still create the wrong policy.
Document old and new sequence
Record what changed so rollback is clear if required traffic stops working.
Hit-counter reasoning
Let controlled traffic show which ACE is matching
A deny ACE counter increases when a required application is tested
That rule is actively matching the required traffic and may be the cause of the failure.
The expected permit ACE remains at zero
Traffic may not be reaching the ACL, may be taking another path, or may be matched by an earlier ACE.
A broad permit has a very high counter
The ACL may be allowing much more traffic than the intended narrow policy.
No ACL counters change during testing
Check interface application, direction, routing path, platform behavior, and whether the traffic actually reaches that interface.
Troubleshooting
Use the failure pattern to narrow the ACL question
Ping works but HTTPS fails
Extended ACL TCP/443 permit, server service state, local firewall, DNS if name-based testing is used.
HTTPS works but SSH fails
TCP/22 ACL entry, first-match ordering, management policy, server SSH state.
All traffic from one subnet fails immediately after ACL application
Implicit deny, overly broad deny, direction, source wildcard, interface placement.
ACL exists but appears to do nothing
Whether it is actually applied to an interface, correct direction, packet path, earlier routing failure.
Only return traffic fails
Reverse-direction filtering, return route, endpoint gateway, ACL on destination-side interface.
One host is blocked instead of the whole subnet
host keyword, wildcard 0.0.0.0, sequence ordering, exact source address.
Evidence-based reasoning
Separate routing failures from policy failures
ACL ends after one permit statement
Weak response
Everything else will be permitted automatically.
Better reasoning
Unmatched traffic reaches the implicit deny, so required additional flows need explicit permit entries.
A deny statement is below a broad permit any
Weak response
The deny will override the permit because deny is stronger.
Better reasoning
ACLs are first-match. The earlier broad permit can prevent the later deny from ever being evaluated.
A standard ACL near the source blocks one subnet
Weak response
That is always ideal because filters belong close to the source.
Better reasoning
Standard ACLs cannot distinguish destinations, so source-side placement may block more destinations than intended.
An ACL counter is zero
Weak response
Delete the ACL because it is unused.
Better reasoning
Zero hits can mean no recent matching traffic, wrong direction, wrong path, or an earlier rule match. Investigate first.
Users cannot reach DNS after hardening
Weak response
Permit UDP 53 and assume the issue is solved permanently.
Better reasoning
Confirm the exact DNS server and whether both UDP and TCP DNS are required by the environment.
A routing table is missing the destination network
Weak response
Rewrite the ACL.
Better reasoning
Fix routing first. ACL policy cannot permit traffic toward a destination the router cannot route.
Unsafe shortcuts
ACL changes that can erase security or break every service
Removing all ACLs to restore connectivity
Can erase required network policy and expose traffic that should remain restricted.
Adding permit ip any any at the top
Makes most later restrictions ineffective because first-match evaluation stops at the broad permit.
Applying an ACL before reading it
The implicit deny or existing entries can immediately disrupt required services.
Guessing wildcard masks
Can match a much larger or smaller address range than intended.
Editing several ACEs at once
Makes it difficult to identify which rule broke or restored traffic.
Ignoring return traffic
Can create one-way sessions that appear partially functional.
Practice scenarios
Choose the safest next policy action
A named ACL permits HTTPS at sequence 20, but sequence 10 already says permit ip any any.
The broad sequence 10 entry matches first, so later filtering is ineffective for most IP traffic. Reorder the policy deliberately.
A /26 network must be matched in an ACL.
Use the correct network address with wildcard 0.0.0.63 rather than copying the subnet mask directly.
The ACL is configured correctly but show ip interface shows no access group applied.
The ACL definition exists but is not filtering that interface. Confirm the intended application point before applying it.
Users can ping the server but cannot access HTTPS.
Check TCP/443 ACL handling and the server service before changing routing or VLAN configuration.
A standard ACL near the source blocks access to every remote network.
Standard ACL placement may be too broad. Re-evaluate where the source-only policy should be applied.
A teammate suggests deleting the ACL to test connectivity.
Prefer a controlled rule-level change or evidence-based test. Removing the entire ACL can erase required protections.
Verification
Prove the policy allows what is required and denies only what should be denied
Policy intent
Each ACE maps to a clear scenario requirement.
Ordering
Specific exceptions appear before broader matching statements when required.
Wildcard
Source and destination ranges match exactly the intended networks or hosts.
Protocol and port
TCP, UDP, ICMP, and service ports reflect the real application requirement.
Interface and direction
The ACL is applied at the intended interface in the correct in/out direction.
Routing
The router has a valid route to the destination before ACL conclusions are made.
Counters
Expected permit or deny counters change when controlled tests are performed.
End-to-end behavior
Required services work and prohibited traffic remains blocked after the change.
Defensive lab
Build and troubleshoot a fictional inter-VLAN ACL policy
Build a fictional topology with Staff VLAN 10, Student VLAN 20, Server VLAN 30, and inter-VLAN routing already verified.
Create server 192.168.30.10 with fictional HTTPS and SSH services and confirm both are reachable before filtering.
Create a named extended ACL that permits Staff HTTPS to the server and denies Staff SSH to that server while preserving other required Staff traffic.
Apply the ACL inbound on the Staff Layer 3 interface and verify the exact interface and direction.
Test HTTPS and SSH separately and inspect ACL hit counters.
Introduce one fictional fault such as placing a broad permit before the SSH deny or using the wrong wildcard mask.
Use show ip access-lists, interface application state, and controlled traffic tests to isolate the exact ACE causing the unexpected behavior.
Correct only that ACE, verify required and prohibited flows, document the final ACL, and save only after the policy behaves as intended.
Lesson checklist
Before moving on
I understand top-down, first-match ACL processing.
I remember that IPv4 ACLs have an implicit deny at the end.
I can distinguish standard and extended ACL capabilities.
I can calculate common wildcard masks.
I understand host and any shortcuts.
I can explain inbound versus outbound from the router interface's perspective.
I inspect routing before assuming an ACL is the problem.
I can verify where an ACL is applied.
I understand why ACL ordering matters.
I use hit counters as evidence instead of deleting rules blindly.
I consider return traffic and application-specific requirements.
I verify required and prohibited flows before saving ACL changes.
Reflection
Check your reasoning
Question 1
Why can an ACL rule be correct but ineffective because of its position?
Question 2
Why is a wildcard mask not the same as a subnet mask?
Question 3
Why are extended ACLs commonly placed closer to the source than standard ACLs?
Question 4
How can ACL counters help distinguish a policy problem from a routing problem?
Question 5
Why does an implicit deny matter when you create a short ACL?
Question 6
What should you verify before removing or broadening an ACL?
Carry this forward
Read ACLs as ordered policy, not as a bag of rules. Verify the route, packet direction, wildcard, protocol, service port, sequence order, hit counters, and return traffic before deciding what needs to change.