Extended ACL: Application Filtering at a Hardened Edge

Bundle lab

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.

Learning objectives

• Design and place an extended ACL near the traffic source; match exact subnets and specific L4 ports.
• Apply an extended ACL inbound on the correct interface and verify ordering, direction, and default deny behavior.
• Harden router VTY access with a standard ACL and SSH-only remote access.
• Use Linux tools (ping, wget, ssh) to validate allowed and denied flows and interpret ACL hit counters.
• Troubleshoot reachability, ACL placement, and static routing on an edge/DMZ topology.

Troubleshooting focus

• CLIENT01 cannot ping 10.10.10.1, or RTR-EDGE1 cannot ping 10.20.20.10: sweep interface status for down/down links and wrong addresses or masks. Fix the plumbing before blaming the ACL.
• The deny entry in show access-lists EDGE-IN-LAN-FILTER still reads zero hits after the failed SSH: the ACL is on the wrong interface or the wrong direction. It belongs inbound on RTR-EDGE1 Ethernet0/0.
• Check the masks — host 10.20.20.10 and 10.10.10.0 0.0.0.255. A 255.255.255.0 mask inverts the logic and blocks valid traffic.
• ping 10.0.0.2 from CLIENT01 fails: this is routing, not filtering. RTR-EDGE1 needs its default route to 10.0.0.2, and RTR-ISP1 needs routes back to the Inside and DMZ subnets via 10.0.0.1.