Access Control Lists (ACLs)

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.

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.

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.

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.

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.

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.

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.

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.

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.

Advanced ACL and NAT capstone, run as a fault hunt. A branch site was cut over last night and the policy does not behave: the flow that should be blocked gets through, other traffic does not come back at all, and nobody recorded what changed. You get symptoms and the required end state — no fault list. The faults span all three routers and include a shadowed ACE and a policy applied on the wrong side of NAT, so translated addresses hide the very hosts the rules name. Expect fixing the first one to change the symptom rather than clear it.