LogoفارسیFA

Hands-On Lab: Configuring Extended Numbered ACLs

This hands-on lab configures an extended numbered ACL to permit only specific traffic types by source, destination, protocol, and port, applying it close to the source and verifying granular filtering that a standard ACL could never achieve.

Extended ACL ConfigurationProtocol and Port FilteringACL Source Placement

~3 min read · Updated Sep 23, 2026

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.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring OSPF Virtual Links

This hands-on lab connects a disconnected area to the backbone using an OSPF virtual link, addressing a design violation where an area does not have a direct physical connection to Area 0, and verifies routes flow correctly once the virtual link is established.

Continue

Hands-On Lab: Configuring an OSPF NSSA Area

This hands-on lab configures Area 1 as an NSSA, redistributing a local external route directly from within that area and verifying it propagates as a Type 7 LSA before being translated to Type 5 at the ABR, while inter-area routes from elsewhere remain blocked exactly as in a standard stub area.

Continue

Hands-On Lab: Configuring OSPF Stub and Totally Stubby Areas

This hands-on lab configures a leaf area as a standard stub area, then upgrades it to a totally stubby area, comparing the routing table size at each stage and verifying only a default route remains once fully configured.

Continue

Hands-On Lab: Configuring Multi-Area OSPF with Route Summarization

This hands-on lab configures multi-area OSPF across three routers, designating an ABR that summarizes several subnets from a leaf area into a single route advertised toward the backbone, tying together the area design and summarization concepts covered earlier in this series.

Continue

Hands-On Lab: Configuring EIGRP for IPv6

This hands-on lab configures EIGRP for IPv6 between two routers, activating the protocol directly on each interface similar to OSPFv3's approach, and highlights the mandatory router ID requirement unique to EIGRPv6.

Continue

Hands-On Lab: Configuring OSPFv3 for IPv6

This hands-on lab configures OSPFv3 between two routers to dynamically route IPv6 traffic, comparing its configuration syntax against the OSPFv2 labs covered earlier in this series while highlighting the interface-level activation approach OSPFv3 uses.

Continue
Previous ArticleNext Article