ACLs evaluate top-down, first match wins. Once a line matches, no later line is checked. If nothing matches, the implicit deny ip any any at the end drops the packet. Standard ACLs (1-99) match source IP only and belong close to the destination. Extended ACLs (100-199) match source + destination + protocol + L4 port and belong close to the source. Named ACLs are the modern preferred style — same matching logic, better editing.
An Access Control List is a permit / deny rule list a router consults as a packet enters or leaves an interface. The list is ordered. The router walks it top-to-bottom and stops the instant a line's match conditions are met — the verdict on that line (permit or deny) is final. Mis-order your lines and your "deny one host, permit everyone else" turns into "deny one host, then permit everyone else plus the host you just tried to deny" because the broader permit line comes first.
This is the single most common ACL mistake on the CCNA, and the one this lab beats into muscle memory. You'll read sample ACLs by hand, build standard and extended and named lists from CLI templates, apply them to interfaces with the correct direction, then drill the matching logic on randomized packets in the browser.
★ WHY ACLS EXIST
Three jobs, one rule list. Each job uses the same syntax — the difference is what you're filtering and where you apply it.
The classic use case — drop packets you don't want crossing this router. "Block 192.168.50.0/24 from reaching the server VLAN", "permit HTTPS to the DMZ web server but nothing else", "deny telnet inbound on the WAN interface". An ACL applied with ip access-group filters traffic in or out of an interface.
An ACL is also a match list for other features. NAT uses an ACL to say "translate these source addresses"; route maps use ACLs to say "redistribute these prefixes"; QoS class-maps use ACLs to say "give priority to these flows". Same syntax — different consumer. The implicit deny still hides at the bottom, but in match-list use it means "anything not listed is not selected" rather than "anything not listed is dropped".
Apply a standard ACL to the VTY lines with access-class to whitelist which source IPs can SSH or telnet to the device. The simplest and most-tested management-plane hardening on the CCNA. Use a standard ACL — VTY filtering is by source IP only.
For Lab 10 you're focused on use case #1 (traffic filtering) plus a brief look at #3 (VTY). NAT-as-match-list shows up properly in Lab 11.
★ HOW AN ACL EVALUATES
Four rules. Memorise these and the entire topic clicks.
- Top-down. The router reads lines in the order they appear in the running-config.
- First match wins. The moment a line's match conditions are met, that line's verdict (permit / deny) is applied — and no further lines are consulted.
- Implicit deny. Every ACL ends with an invisible
deny ip any any. If no line matches, the packet is dropped. - One ACL per interface per direction per protocol. You can attach one IPv4 ACL in and one IPv4 ACL out on an interface. Not two of either.
If your ACL is supposed to block one specific host inside a larger subnet you're otherwise permitting, the deny line for that host must come first:
Rule of thumb: specific entries above general entries, always.
★ WILDCARD MASKS — THE ONE THING YOU HAVE TO INTERNALISE
Cisco ACLs match address ranges with wildcard masks, not subnet masks. A wildcard mask is the bit-by-bit inverse of a subnet mask:
| PREFIX | SUBNET MASK | WILDCARD MASK | MEANS "MATCH..." |
|---|---|---|---|
| /32 | 255.255.255.255 | 0.0.0.0 | a single host (every bit must match) |
| /30 | 255.255.255.252 | 0.0.0.3 | 4 addresses (P2P link) |
| /29 | 255.255.255.248 | 0.0.0.7 | 8 addresses |
| /24 | 255.255.255.0 | 0.0.0.255 | whole /24 (256 addresses) |
| /16 | 255.255.0.0 | 0.0.255.255 | whole /16 |
| /0 | 0.0.0.0 | 255.255.255.255 | any address (alias: any) |
any is shorthand for 0.0.0.0 255.255.255.255. host 10.1.1.1 is shorthand for 10.1.1.1 0.0.0.0. The CLI will rewrite either form into the verbose pair when you save — same matching, more readable.
Wildcard masks don't have to align with subnet boundaries — you can match every even-numbered host with 0.0.0.254 if you want, by setting the don't-care bits non-contiguously. The CCNA exam only tests contiguous wildcard masks (the inverse of a real subnet mask) but the syntax allows worse.
★ STANDARD VS EXTENDED VS NAMED — WHICH TO REACH FOR
| TYPE | NUMBER RANGE | MATCHES ON | PLACE IT... |
|---|---|---|---|
| Standard | 1-99 & 1300-1999 | source IP only | close to destination |
| Extended | 100-199 & 2000-2699 | src + dst + proto + L4 port + TCP flags | close to source |
| Named | no number — string name | whatever you declare (standard or extended) | same as its underlying type |
A standard ACL filters on source IP only. Drop it too close to the source and you may block traffic to other destinations the source was legitimately allowed to reach. Apply it on the last router before the destination so only the targeted destination is filtered. Extended ACLs match both source and destination, so dropping them at the source is safe and avoids hauling about-to-be-dropped traffic across the WAN.
★ TASK 1 — READ A STANDARD ACL BY HAND
The list below is applied in on R1's G0/1 (the LAN-facing interface). For each test packet, walk the lines top-down and predict the verdict before looking at the answer.
Test packets:
- Source 192.168.1.50 → ?
- Source 192.168.1.100 → ?
- Source 192.168.1.10 → ?
- Source 10.0.0.5 → ?
- DENY — line 1 matches (
host 192.168.1.50). Stops there. - DENY — line 2 matches.
192.168.1.96 0.0.0.31covers.96through.127;.100falls inside it. (Wildcard0.0.0.31= last 5 bits don't-care = 32-address block.) - PERMIT — lines 1 and 2 don't match; line 3 permits the whole
/24. - DENY — no line matches 10.0.0.5. Implicit
deny ip any anydrops it. This is the trap on every "what if no line matches?" exam question.
★ TASK 2 — BUILD A STANDARD ACL
Requirement: on R1, block the host 10.1.1.99 from reaching the 10.2.2.0/24 LAN, while permitting the rest of 10.1.1.0/24 through. Apply it to the LAN-facing interface on R1.
G0/1 is the interface that exits toward the destination LAN. Applying out means "filter as the packet leaves R1 heading for 10.2.2.0/24" — exactly the "close to destination" rule. Applying in on R1's G0/0 (LAN side of the source) would also work, but blocks 10.1.1.99 from reaching any destination through R1 — usually broader than you want.
★ TASK 3 — BUILD AN EXTENDED ACL
Requirement: from the 192.168.10.0/24 LAN, permit only HTTP, HTTPS, and DNS to the internet; deny everything else. Apply it as close to the source as possible (the LAN-side interface on R1).
The implicit deny ip any any drops silently. Add an explicit deny ip any any log as the last line and you get syslog entries every time the ACL drops something — invaluable for troubleshooting. It does not change behaviour; it adds visibility.
If you apply this list outbound on the WAN interface and then add a second extended ACL inbound, you'll need to permit the return traffic. The classic CCNA way is the established keyword on TCP — it matches only segments with the ACK or RST flag set, i.e. responses to a connection your inside host opened.
Applied inbound on the WAN interface — only returning TCP traffic survives.
★ TASK 4 — CONVERT TO NAMED ACL
Named ACLs are the modern preferred style. Same matching logic, much better editing — you can insert lines by sequence number, delete a single line by number, and the name itself documents intent. Rebuild the previous extended ACL as named:
Insert a new line between 20 and 30 — say "permit ICMP echo to the management subnet" — without rebuilding the whole list:
Insert / delete / re-sequence — all by line number — without removing and re-pasting the entire list. With numbered ACLs you have to no access-list 110 the whole thing and rebuild it from scratch to change line ordering. On a 40-line production ACL that's a recipe for an outage. Use named ACLs for anything you'll edit more than once.
★ TASK 5 — PROTECT THE VTY LINES
Restrict SSH/telnet access to the device to a single admin subnet. This is a standard-ACL job (source IP only) applied with access-class, not ip access-group:
ip access-group attaches an ACL to a physical interface to filter transit traffic. access-class attaches a standard ACL to vty lines to filter who can log in. Different commands, different scopes — and a common exam-day mix-up.
★ TASK 6 — DRILL IT LIVE
Reading ACLs on paper builds the model; speed comes from repetition. The ACL Matching Drill generates random ACL + packet pairs and asks you to pick the line that matches first. Standard mode (numbered 1-99, source IP only) → extended mode (numbered 100-199, full 5-tuple) → mixed.
Every answer expands to a field-by-field walkthrough showing exactly which condition matched (or failed to) on each line. When you pick a line that would have matched but isn't the first one, the drill calls it out as the classic trap — that's the line ordering mistake you read about in Task 1.
★ ANALYSIS QUESTIONS
- What is the wildcard mask equivalent of subnet mask 255.255.240.0?
- Why is "specific to general" line ordering critical in an ACL?
- Where do you apply a standard ACL — close to the source or close to the destination — and why?
- Which command applies an ACL to vty lines, and what type of ACL would you use?
- What does the
establishedkeyword on a TCP extended ACL match?
0.0.15.255. /20 = 255.255.240.0 = 11111111.11111111.11110000.00000000. Wildcard is the inverse: 00000000.00000000.00001111.11111111 =0.0.15.255. Fast check: 256 − (last non-zero subnet-mask octet). 240 → 16 → wildcard last non-zero octet = 15.- First-match-wins. A broader permit line above a specific deny line means the specific deny is never reached. Always place narrower rules above broader ones — host before subnet, subnet before any.
- Close to the destination. Standard ACLs match only on source IP, so dropping the packet at the source-side router would also block that source from reaching legitimate destinations. Place it on the last router before the destination so only the intended destination is filtered.
access-class <name|number> inunderline vty 0 15, using a standard ACL (you're filtering by source IP only — who is allowed to log in).- TCP segments with ACK or RST set, i.e. return traffic for a connection that an inside host already opened. Used inbound on the WAN to allow replies through a stateless ACL without permitting unsolicited inbound TCP.
★ VERIFICATION CHECKLIST
- ☐ Standard ACL built, applied with
ip access-group N outclose to the destination, verified withshow ip interface. - ☐ Extended ACL built, applied in on the LAN-facing interface (close to source), explicit
deny ip any any logas the last line. - ☐ Named ACL created with
ip access-list extended NAME, a line inserted by sequence number without rebuilding the whole list. - ☐ VTY lines protected with
access-class+ standard ACL;show run | section line vtyshows the binding. - ☐ All five analysis questions answered correctly.
- ☐ At least one round through Standard mode of the ACL Matching Drill, ideally one round of Extended too.
★ COMMON GOTCHAS
Symptom: access-list 10 permit 192.168.1.0 255.255.255.0 is accepted by the parser but matches nothing you expected.
Fix: Wildcard masks are the inverse of subnet masks. /24 = wildcard 0.0.0.255, not 255.255.255.0. The CLI doesn't reject the typo — it just builds an ACL that almost never matches. Always sanity-check with show access-lists.
Symptom: "I added a deny host 192.168.1.50 after a permit 192.168.1.0 0.0.0.255 and the host still gets through."
Fix: First match wins. Move the deny line above the permit. With numbered ACLs you have to no access-list 10 the whole thing and rebuild — another reason to use named ACLs from the start.
Symptom: "I added one permit line and now nothing else works."
Fix: Every ACL ends with deny ip any any — invisible in show run, real in operation. A list with one permit line denies everything else. If you want "permit one specific thing, allow everything else", you need an explicit permit ip any any after the specific permit.
Symptom: ACL is correct but no traffic is matching, or the wrong traffic is matching.
Fix: Direction is from the router's perspective. in = packet entering the interface from the wire. out = packet leaving the interface onto the wire. A LAN-side ACL filtering outbound internet traffic is applied in on the LAN interface (entering the router from the LAN), not out.
Symptom: Applied access-class on vty 0 15 from a remote session — connection drops, can't get back in.
Fix: Apply VTY ACL changes from console, or include your current source IP in the ACL before attaching it to the vty lines. reload in 5 as a safety net — if you misconfigure, the router reverts and reboots after 5 minutes; if it works, reload cancel within those 5 minutes.
★ VERIFICATION CHEAT SHEET
★ THINGS WORTH TRIGGERING
After applying an ACL, run show access-lists a few times while traffic flows. The counters next to each line show how many packets matched. If one line is at zero and your problem traffic is being matched by a different line — that's your ordering bug.
Add log to any individual line and IOS sends a syslog message every time that line matches (rate-limited so it doesn't drown your console). Useful when you suspect an ACL is dropping traffic it shouldn't — turn on logging temporarily, watch the log, then take logging back off.
After many insertions, a named ACL's line numbers can get awkward (e.g. 5, 7, 8, 10, 13, 25). Run ip access-list resequence WEB-OUT 10 10 and IOS renumbers every line — starting at 10, stepping by 10. Cleans up the show output without changing behaviour.
Beyond CCNA, but worth a peek: time-range BUSINESS-HOURS + a permit line that references it = an ACL that only matches between specified hours / days. Try it in a lab once so you know it exists when an interviewer asks.
★ COMPARE TO LAB 9 — DISCOVERY vs FILTERING
In Lab 9 (CDP & LLDP) the security move was information hiding — turn off discovery on edge ports so untrusted networks don't see your hostname, IOS version, and topology. ACLs are the next layer: even with discovery off, an attacker on an edge port can still send packets. The ACL is the rule list that decides what actually traverses your router. CDP/LLDP harden the management plane's visibility; ACLs harden the data plane's reachability.
Both belong on every CCNA candidate's security checklist for Domain 5. Both are exam favourites.
★ WHY THIS LAB IS A BROWSER LAB, NOT A .PKT
ACL evaluation is a mental model problem more than a configuration problem. The syntax is easy; sustained correctness under timed exam pressure is hard. A Packet Tracer file would teach you the same syntax already in this doc plus a single static topology — but it can't randomise the ACL + packet pairs the way the in-browser drill can. To build CCNA-grade speed you need dozens of fresh ACL/packet combinations, not three.
So the lab pairs this writeup (the why and the syntax) with the ACL Matching Drill (the reps). Read the doc once, then drill until field-by-field evaluation is instant.
Wendell Odom's chapters on ACLs (Domain 5) are the canonical written reference for everything in this lab — read those alongside the drill for full coverage. Amazon affiliate.