Hands-On Lab: Configuring Extended Numbered ACLs

Lab Objective

Configure an extended numbered ACL permitting only web traffic (HTTP and HTTPS) from a specific subnet to any destination, apply it close to the source, and verify both permitted and denied traffic types behave correctly.

Lab Purpose

Extended ACLs, discussed earlier in this series, add source, destination, protocol, and port matching that standard ACLs cannot provide, enabling far more precise security policy than simply blocking or permitting an entire subnet's traffic.

Lab Topology

R1
  Gi0/0: 192.168.25.1/24 (internal LAN)
  Gi0/1: 203.0.113.1/30 (WAN, toward internet)

Task 1: Configure Basic Addressing

Configure both interfaces as shown.

Task 2: Create the Extended ACL

Create numbered ACL 100 permitting only HTTP (port 80) and HTTPS (port 443) traffic from 192.168.25.0/24 to any destination, denying everything else.

Task 3: Apply the ACL Close to the Source

Apply the ACL inbound on Gi0/0, consistent with extended ACL placement best practice.

Task 4: Verify Permitted Web Traffic

Confirm an internal host can successfully reach an HTTPS server.

Task 5: Verify Denied Non-Web Traffic

Confirm the same internal host cannot successfully ping an external address, since ICMP is not permitted.

Solution and Verification

R1(config)# interface gigabitethernet0/0
R1(config-if)# ip address 192.168.25.1 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# exit
R1(config)# interface gigabitethernet0/1
R1(config-if)# ip address 203.0.113.1 255.255.255.252
R1(config-if)# no shutdown

R1(config)# access-list 100 permit tcp 192.168.25.0 0.0.0.255 any eq 80
R1(config)# access-list 100 permit tcp 192.168.25.0 0.0.0.255 any eq 443

R1(config)# interface gigabitethernet0/0
R1(config-if)# ip access-group 100 in

-- Applied close to the source, since extended
-- ACLs can already match on the specific
-- destination and do not risk the same
-- unintended-blocking concern that placed
-- standard ACLs near the destination instead

Internal-PC (192.168.25.10)> curl https://93.184.216.34

-- Successful HTTPS connection

Internal-PC (192.168.25.10)> ping 93.184.216.34

Request timed out.
Request timed out.
Success rate is 0 percent (0/5)
-- ICMP is not permitted by the ACL, so it
-- falls to the implicit deny -- even though
-- HTTPS to the same destination address works
-- perfectly, confirming the filtering is
-- genuinely based on protocol and port, not
-- just destination reachability in general

R1# show access-lists

Extended IP access list 100
    10 permit tcp 192.168.25.0 0.0.0.255 any eq www (12 matches)
    20 permit tcp 192.168.25.0 0.0.0.255 any eq 443 (34 matches)

Key Takeaway

An extended ACL's ability to match on protocol and port is what allows genuinely fine-grained policy like "permit web traffic but nothing else" — a standard ACL, discussed earlier in this series, could only ever achieve an all-or-nothing decision based on source address alone, making it fundamentally incapable of this level of precision.