CCNA NAT4: PAT Overload onto a Pool
Implement Port Address Translation (PAT) using a one-address NAT pool so multiple inside hosts share a single public IP. Reuse the same 5-node topology and addressing as the prior lab; convert the pool to a single address and enable overload. Verify simultaneous connectivity from two inside hosts, observe translations and counters, and contrast with prior pool-exhaustion behavior.
NAT Selection with an ACL: PAT a Single Host Only
Configure PAT on an edge router so only PC-A is translated using a standard ACL as the traffic selector. PC-B remains untranslated and fails to reach the ISP, illustrating that NAT occurs only for traffic explicitly matched by the ACL. Validate using host pings and IOS show commands, and interpret ACL hit counters and NAT tables.
PAT onto the Outside Interface (SOHO Edge)
Implement and verify interface-based PAT (overload) on a single-edge SOHO router. Inside hosts on 192.168.10.0/24 share the router’s lone public IP (203.0.113.1) on its outside interface. Validate NAT translations, ACL matches, and simultaneous host access, and practice troubleshooting common misconfigurations (inside/outside role reversal, ACL selection errors).
NAT at the Internet Edge with Default Routing
Build an Internet-edge NAT design that reaches beyond the ISP to a real external network. You will configure dynamic PAT (overload) from a private LAN to a public /29 using a NAT pool on the edge router, with the router’s default route already pointing to the ISP. Verify that an inside host can reach a public server across the ISP and that translations, counters, and default routing reflect the expected state.
CCNA NAT3: Dynamic NAT with an Address Pool
Configure dynamic one-to-one NAT using a public address pool on an IOS router between a private LAN and a simulated ISP. Two inside hosts draw from a two-address public pool on-demand. Validate that no translations exist before traffic, that each host receives a distinct global address after generating traffic, and that entries age out when idle.
NAT Troubleshooting Capstone: Interface Role + ACL
Advanced CCNA NAT/PAT troubleshooting on a compact 5-node CML-Free topology. A pre-broken edge (R1) sits between a private LAN and an ISP transit. Learners diagnose why inside-to-outside traffic never translates: the NAT interface roles are incorrect and the ACL referenced by NAT does not match the actual inside subnet. Fix both independently to restore translations, then verify from hosts and with IOS show commands.
CCNA NAT9: Verifying & Clearing NAT
Operate, observe, and clear Cisco IOS PAT translations on an internet edge. You will configure a standard PAT overload on R1, generate multiple concurrent sessions from an inside host, read translation/state counters, and clear single and all entries to see how the table repopulates immediately under live traffic.
ACL Troubleshooting Capstone: Classic Faults, NAT, Placement
Diagnose and repair an ACL + NAT policy on a small branch-to-DC topology. Implement PAT on the branch edge, correctly place an extended ACL to filter pre-NAT traffic, prove a permitted flow and a denied flow from the end host, and validate with show commands.
Extended ACL Fundamentals: Permit HTTP, Deny Others
Deploy a numbered extended ACL on a router-on-a-stick topology to allow HTTP from a single approved client to a web server while denying all other TCP attempts to that server from the same user VLAN. Apply the ACL inbound near the source, verify with real client traffic, and troubleshoot using ACL hit counts and test flows.
Selective Inter-VLAN Reachability: Guest Isolation
Build a router-on-a-stick design with three VLANs (SALES, HR, GUEST) on a single router and single access switch, then enforce guest isolation using a single extended ACL applied inbound on the Guest subinterface. SALES and HR can reach each other; GUEST can reach only its default gateway and is blocked from internal subnets. The lab focuses on correct 802.1Q tagging, trunking, access port assignments, ACL placement/order, and end-host verification.
Extended ACL: Application Filtering at a Hardened Edge
Build a 5-node edge/DMZ topology. Implement a named extended ACL on the EDGE router to allow only TCP/80, TCP/443, and ICMP echo from the Inside LAN to a DMZ web server, deny all other traffic to that server with logging, and still permit general traffic elsewhere. Apply the ACL inbound on the EDGE inside LAN interface. Harden router SSH management with a standard ACL. Verify with wget, ping, and an intentionally denied SSH attempt that increments the deny log counter.
Standard ACL: Permit Host & Subnet, Deny Others
Beginner CCNA ACL lab on a compact 5-node CML-Free topology. You will configure static routing end-to-end, implement source NAT (PAT) at the source edge, and then build a standard numbered ACL near the destination to allow a single NATed host and a specific subnet while denying all others. You will validate with pings from end hosts, observe ACL hit counters and NAT translations, and troubleshoot common mistakes such as ACL placement, wildcard masks, and pre-/post-NAT address matching.
Secure Router VTY with ACL: Only Management Host Allowed
Configure a standard IPv4 ACL and bind it to the VTY lines on the HQ router so only the dedicated management host can SSH to it. Confirm that regular routed traffic between sites is unaffected, and prove both a permitted and a denied management attempt.
CCNA: Named ACLs & Editing by Sequence Number
Hands-on ACL practice using named standard and extended ACLs, applied with correct placement and direction, edited by sequence number, and verified with counters and end-host tests. The lab adds a realistic NAT edge to expose order-of-operations pitfalls without obscuring data-plane ACL effects.
ACL Wildcard Masks: Match Host, Subnet, and Range
Hands-on CCNA ACL practice using standard ACLs and wildcard masks to allow a single host, a contiguous range, and an entire subnet while proving a deny. You will place the ACL near the destination, order statements correctly, verify with end-host pings and ACL counters, and troubleshoot common mistakes.
CCNA: ACL Placement – Std Near Dest, Ext Near Source
Dual-router Branch/HQ lab with a branch client and an HQ server. You will apply an extended IPv4 ACL inbound near the source on the Branch LAN to block specific traffic (TCP/80) while permitting others (ICMP), and a standard IPv4 ACL outbound near the destination on the HQ LAN to admit only the approved source. Validate from real hosts, confirm ACL hitcounts, and keep inter-site connectivity via static routes over a /30 transit.
ACL Logging & Order: Correct Permit/Deny Sequencing
Three-router static-routing lab with two Linux endpoints. An extended IPv4 ACL is intentionally misordered inbound near the source, causing Telnet to be permitted unexpectedly. Learners must observe first-match behavior via hit counters, enable buffered logging to see ACL log entries, and then correct the ACL sequence so Telnet is blocked while SSH and ICMP are permitted. All routers include a complete SSH management plane. The final solution forwards end-to-end and is enterprise-clean.
ACL Segmentation Policy on Multi-LAN Router
Deploy and verify multiple IPv4 ACLs on a single router that terminates three distinct LANs (Client, Server, and Management). You will place an extended ACL inbound on the Client interface to allow only specific services to the Server and block access to Management, a standard ACL outbound on the Management interface to enforce destination-side protection by source, and a VTY access-class to restrict router SSH to the Management subnet only. Validate with end-host tests that permitted flows succeed while denied flows are provably blocked, and use ACL hit counts and logs to troubleshoot.
ACL App Filter: Permit SSH/HTTP, Block Telnet/ICMP
Build a two-router, one-access-switch lab with a client and a server. Establish basic IP connectivity with static routing, then implement an extended IPv4 ACL inbound on the client-facing interface to permit SSH and HTTP to the server while denying Telnet and ICMP echo. Validate from the client and review ACL hit counters for proof.
Practicing access control lists (ACLs) on Cisco Modeling Labs
Access control lists are where a lot of engineers lose points — not because the syntax is hard, but because ACLs are unforgiving about direction, order, and placement. A standard ACL belongs near the destination; an extended ACL belongs near the source; the implicit deny any at the end catches everything you forgot; and one line in the wrong order shadows the rest. You learn that fastest by applying an ACL, testing it, and watching the wrong traffic get through.
These ACL labs run on real Cisco IOS in Cisco Modeling Labs. You'll write standard and extended, numbered and named ACLs, match hosts, subnets, and ranges with wildcard masks, secure VTY access with access-class, and place each ACL in the correct direction on the correct interface. Verify with show access-lists and targeted connectivity tests, then upload your export for grading that checks the policy actually permits and denies the right traffic. Break/fix labs inject the classic faults: a reversed direction, a shadowed ACE, an off-by-one wildcard mask, an ACL applied on the wrong interface.
Frequently asked questions
What's the difference between a standard and an extended ACL?
A standard ACL matches only the source address and is placed close to the destination; an extended ACL matches source, destination, protocol, and ports and is placed close to the source. The labs have you build and correctly place both.
Do the ACL labs cover wildcard masks?
Yes — matching a single host, a subnet, and an address range, including the negative-test math that trips people up. Getting the wildcard wrong is one of the built-in faults you'll troubleshoot.
Can I practice securing router management with ACLs?
Yes. Several labs use access-class on the VTY lines so only an approved management host can reach the device over SSH — a common exam and real-world task.