Extended ACL Fundamentals: Permit HTTP, Deny Others

Bundle lab

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.

Learning objectives

• Design and apply a numbered extended IPv4 ACL that matches source, destination, protocol, and TCP port.
• Place an extended ACL near the source and apply in the correct direction to filter intended traffic.
• Allow HTTP (TCP/80) from a specific client to a web server; deny other TCP flows to that server.
• Verify operational impact with ACL hit counts and real traffic generation from end hosts.
• Troubleshoot ACL order, placement, and direction issues that cause unexpected denials.

Troubleshooting focus

• HTTP from CLIENT-ALLOWED to 10.30.30.10 fails: read show ip access-lists 110. A deny ahead of the specific host permit blocks the approved client — put the specific permit first.
• HTTP from CLIENT-ALLOWED fails even with the order correct: verify the web server on SRV-WEB01 is running and listening on TCP/80, and its IP and gateway are right.
• CLIENT-DENIED still reaches the server, or the counters never move: the list is on the wrong interface. It belongs inbound on Ethernet0/0.10, not Ethernet0/0 or Ethernet0/0.30.
• The SYN passes but the response does not: the ACL is applied outbound or on the return path.
• Ping to 10.30.30.10 breaks too: the list has no final catch-all permit, so the implicit deny drops non-TCP traffic. Add one at the end.
• Both clients fail completely, no pings: confirm the trunk allows VLANs 10 and 30 and the access ports are correct.