Extended ACL Syntax

Lab Objectives

• Understand the syntax of Extended Access Control Lists (ACLs): protocol, source, source wildcard, destination, destination wildcard, and port operators.
• Practice the operators eq, gt, lt, and range when filtering TCP/UDP ports.
• Verify ACL behavior with show commands and troubleshoot a common misconfiguration.

Note: The topology and IP addresses used are the exact base lab topology. In production networks, extended ACLs are used at network edges to control which application traffic can enter or leave an environment — for example, allowing outbound web traffic but blocking inbound management ports.

ASCII Topology (BASE LAB TOPOLOGY — exact IPs on every interface)

                [Internet]
               203.0.113.1
                    |
               R1 (Gateway)
              Gi0/0: 10.10.10.1
              Gi0/1: 10.10.20.1
              Gi0/2: 10.10.30.1
              /     |     \
           R2      R3      R4

Gi0/0: 10.10.10.2 Gi0/0: 10.10.20.2 Gi0/0: 10.10.30.2 Gi0/1: 10.10.40.1 / \ | S1 S2 S3 / \ | /
PC1 PC2 PC3 PC4 PC5

IP SCHEME (for reference)

• 10.10.10.0/24 — R1-R2 link
• 10.10.20.0/24 — R1-R3 link
• 10.10.30.0/24 — R1-R4 link
• 10.10.40.0/24 — R2-S1 link
• 192.168.1.0/24 — VLAN 10 (Sales)
• 192.168.2.0/24 — VLAN 20 (Engineering)
• 192.168.3.0/24 — VLAN 30 (Management)
• 203.0.113.0/24 — Public/Internet simulation

---

Lab Tasks (Try It Yourself First!)

Complete these tasks WITHOUT looking at the solution below. Use ? and show commands to figure it out.

Task 1: Create an Extended ACL to block web traffic from Sales to the Internet

Configure a numbered extended ACL (100-series) that denies TCP port 80 (HTTP) from the Sales subnet (192.168.1.0/24) to the Internet (203.0.113.0/24) but allows other traffic. Apply the ACL inbound on R1’s Gi0/2 (toward R4/Internet).

Task 2: Use port operator eq to block TFTP from Engineering to Management

Create a separate numbered extended ACL that denies UDP port 69 (TFTP) from Engineering (192.168.2.0/24) to Management (192.168.3.0/24) and allows other traffic. Use eq for the port operator.

Task 3: Demonstrate gt, lt, and range operators

Create an ACL demonstrating:

• gt — deny TCP connections from any host in Engineering to any destination with source port greater than 1023.
• lt — allow TCP from Management to R1 if destination port is less than 1024.
• range — permit UDP ports in the ephemeral range 1024–2048 from Sales to R2’s 10.10.10.2.

Apply these ACLs where appropriate for testing.

Think About It: Why does ACL order matter for extended ACLs? Consider what happens if you place a permissive statement before a deny for a specific flow.

---

Lab Solution

Task 1 Solution: Block HTTP from Sales to Internet

What we are doing: We create a numbered extended ACL (101) that specifically denies TCP port 80 from the Sales network to the Internet network, then permits other IP traffic. We apply it inbound on R1 Gi0/2 so traffic leaving the Sales subnet towards the Internet is inspected.

R1(config)# access-list 101 deny tcp 192.168.1.0 0.0.0.255 203.0.113.0 0.0.0.255 eq 80
R1(config)# access-list 101 permit ip any any
R1(config)# interface GigabitEthernet0/2
R1(config-if)# ip access-group 101 in

• The first command creates an extended ACL entry denying TCP where source is 192.168.1.0/24 (wildcard 0.0.0.255), destination is 203.0.113.0/24, and destination port equals 80. This is a specific deny for HTTP.
• The second command permits all other IP traffic — necessary because ACLs have an implicit "deny ip any any" at the end; without an explicit permit, legitimate traffic would be blocked.
• The third and fourth commands bind the ACL inbound on Gi0/2 so packets entering that interface are filtered.

Verify:

R1# show access-lists 101
Extended IP access list 101
    deny tcp 192.168.1.0 0.0.0.255 203.0.113.0 0.0.0.255 eq 80
    permit ip any any

Why this matters: In production, placing precise denies prevents unintended service outages. The explicit permit ip any any prevents accidental total loss of connectivity because of the implicit deny.

Task 2 Solution: Deny TFTP using eq

What we are doing: We build ACL 102 to deny UDP port 69 (TFTP) from the Engineering subnet to Management. This uses the eq operator for matching a specific UDP port.

R1(config)# access-list 102 deny udp 192.168.2.0 0.0.0.255 192.168.3.0 0.0.0.255 eq 69
R1(config)# access-list 102 permit ip any any
R1(config)# interface GigabitEthernet0/1
R1(config-if)# ip access-group 102 in

• deny udp ... eq 69 matches UDP traffic where destination port is exactly 69.
• permit ip any any again ensures other traffic continues to flow.
• Applying on Gi0/1 (link toward R3 and internal networks) filters internal cross-subnet traffic.

Verify:

R1# show access-lists 102
Extended IP access list 102
    deny udp 192.168.2.0 0.0.0.255 192.168.3.0 0.0.0.255 eq 69
    permit ip any any

Tip: The reference material shows access-list 102 permit udp any any eq 69 — here we adapt that syntax to a deny with source/destination subnets.

Task 3 Solution: Using gt, lt, and range

What we are doing: We create ACL 110 to demonstrate gt, lt, and range. These operators are used to match port numbers relative to a value or within a range.

R1(config)# access-list 110 deny tcp 192.168.2.0 0.0.0.255 any gt 1023
R1(config)# access-list 110 permit tcp 192.168.3.0 0.0.0.255 any lt 1024
R1(config)# access-list 110 permit udp 192.168.1.0 0.0.0.255 host 10.10.10.2 range 1024 2048
R1(config)# access-list 110 permit ip any any
R1(config)# interface GigabitEthernet0/0
R1(config-if)# ip access-group 110 in

• deny tcp ... gt 1023 matches TCP packets where the destination port is greater than 1023 (commonly ephemeral ports). This can be used to block high-source-port-based connections if needed.
• permit tcp ... lt 1024 allows well-known ports (port numbers less than 1024) from Management to any destination — useful for allowing management protocols.
• permit udp ... host 10.10.10.2 range 1024 2048 allows UDP ports in a contiguous range from Sales to R2.
• permit ip any any avoids unintentionally blocking traffic.

Verify:

R1# show access-lists 110
Extended IP access list 110
    deny tcp 192.168.2.0 0.0.0.255 any gt 1023
    permit tcp 192.168.3.0 0.0.0.255 any lt 1024
    permit udp 192.168.1.0 0.0.0.255 host 10.10.10.2 range 1024 2048
    permit ip any any

Real-world context: gt/lt/range let you filter classes of ports without enumerating every port number. In data centers this is handy for permitting only well-known service ports while denying high-numbered ephemeral ports in sensitive segments.

---

Troubleshooting Scenario

Scenario: HTTP blocked for Sales, but SSH is also failing

Symptom: After applying ACL 101, users in Sales cannot SSH to external hosts although you only meant to block HTTP.

Your task: Find and fix the issue.
Hint: Look at ACL order and the wildcard masks.

Solution:

• Check ACL order and entries:

R1# show access-lists 101

• If the ACL uses deny tcp 192.168.1.0 0.0.0.255 203.0.113.0 0.0.0.255 eq 80 followed by permit ip any any the ACL is correct. If instead permit ip any any comes first, it will allow everything (including HTTP) and the deny will never match. If SSH is failing, confirm the ACL is applied on the correct interface and direction.
• Fix: Reapply ACL in correct order or reapply to correct interface. Example to remove and re-add:

R1(config)# no access-list 101
R1(config)# access-list 101 deny tcp 192.168.1.0 0.0.0.255 203.0.113.0 0.0.0.255 eq 80
R1(config)# access-list 101 permit ip any any

Explanation: ACLs are processed top-to-bottom; an early overly-broad statement can override specific denies.

---

Verification Checklist

• show access-lists 101 shows the HTTP deny and permit ip any any
• show access-lists 102 shows the UDP 69 deny for Engineering → Management
• show access-lists 110 lists gt, lt, and range entries as configured
• ip access-group commands are applied to the correct interfaces and directions

Common Mistakes

Symptom	Cause	Fix
HTTP still allowed	ACL not applied on correct interface/direction	Apply ACL inbound on Gi0/2: ip access-group 101 in
All traffic blocked from a subnet	Missing final permit ip any any (implicit deny active)	Add access-list <num> permit ip any any or explicit permits
ACL not matching expected hosts	Incorrect wildcard mask (used mask instead of wildcard)	Use wildcard 0.0.0.255 for /24 networks
ACL order causes no effect	Permit placed before specific deny	Reorder ACL so specific denies are before broad permits (recreate ACL)

Challenge Task

Configure a single numbered extended ACL that:

• Denies inbound SSH (tcp eq 22) from the Internet 203.0.113.0/24 to Management 192.168.3.0/24,
• Allows HTTPS (tcp eq 443) from Sales to the Internet,
• Logs denied attempts,
• Apply it on the interface toward the Internet.

(No step-by-step — use your knowledge of extended ACL syntax, log keyword, and interface application.)

Important: Always test ACLs in a lab before deploying to production. Extended ACLs are powerful but order-sensitive — think of them as a top-to-bottom rule book that stops at the first match.