Extended ACL Challenge

Lab Objectives

• Configure extended access control lists (ACLs) to allow HTTP/HTTPS, block SSH, and permit ICMP from a specific subnet.
• Apply ACLs on the appropriate router interfaces and verify behavior with IOS show commands.
• Understand ACL ordering, real-world use cases, and troubleshooting techniques.

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 and apply an extended ACL on R1 (outbound Gi0/0)

Build an extended numbered ACL (101) and apply it outbound on R1 Gi0/0 so that:

• Allow HTTP (TCP/80) and HTTPS (TCP/443) from Sales (192.168.1.0/24) and Engineering (192.168.2.0/24) to the Internet.
• Permit ICMP from Management (192.168.3.0/24) to the Internet for monitoring.
• Deny SSH (TCP/22) from anywhere to the Internet.
• Permit all other IP traffic (so normal services continue unless explicitly blocked).

Task 2: Prevent inter-VLAN SSH on R2 (inbound Gi0/1)

On R2, apply an extended ACL (102) inbound on Gi0/1 to:

• Deny SSH (TCP/22) between Sales (192.168.1.0/24) and Engineering (192.168.2.0/24) in both directions.
• Allow remaining traffic between those subnets.

Task 3: Enable logging for denied SSH attempts on R1

Modify the outbound ACL on R1 so the SSH deny entry logs matches. This helps network ops see attempted SSH to the Internet in the router logs.

Think About It: Why must the ACL permit the web and ICMP entries before the SSH deny? How does ACL order affect which traffic is matched?

---

Lab Solution

(Use the exact topology and IPs shown below.)

                [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.30.2 Gi0/1: 10.10.40.1 | / \ | S1 S2 S3 / \ | /
PC1 PC2 PC3 PC4 PC5

Task 1 Solution: Configure ACL 101 on R1 and apply outbound on Gi0/0

What we are doing: Create an extended ACL that selectively allows web traffic from Sales/Engineering, permits management ICMP, blocks SSH to the Internet, then allows other traffic. Apply it outbound on R1 Gi0/0 (the interface toward the Internet) so packets leaving for 203.0.113.0/24 are filtered.

R1# configure terminal
R1(config)# access-list 101 permit tcp 192.168.1.0 0.0.0.255 any eq 80
R1(config)# access-list 101 permit tcp 192.168.1.0 0.0.0.255 any eq 443
R1(config)# access-list 101 permit tcp 192.168.2.0 0.0.0.255 any eq 80
R1(config)# access-list 101 permit tcp 192.168.2.0 0.0.0.255 any eq 443
R1(config)# access-list 101 permit icmp 192.168.3.0 0.0.0.255 any
R1(config)# access-list 101 deny tcp any any eq 22
R1(config)# access-list 101 permit ip any any
R1(config)# interface GigabitEthernet0/0
R1(config-if)# ip access-group 101 out
R1(config-if)# end

What just happened:

• access-list 101 permit tcp 192.168.1.0 0.0.0.255 any eq 80 — permits TCP port 80 from the Sales subnet to any destination. This is important because extended ACLs match source, destination and protocol/port; placing specific allows first ensures web traffic is permitted before a deny catches it.
• Similar lines permit HTTPS and also allow Sales and Engineering web to leave.
• access-list 101 permit icmp 192.168.3.0 0.0.0.255 any — allows management hosts to use ping/ICMP to the Internet (used for monitoring).
• access-list 101 deny tcp any any eq 22 — explicitly blocks SSH to the Internet, preventing internal hosts from establishing outbound SSH sessions.
• access-list 101 permit ip any any — a permissive catch-all so non-specified traffic continues, preventing accidental service outages. (In production you might avoid a broad permit and instead enumerate allowed services.)
• Applied the ACL outbound on GigabitEthernet0/0 so packets leaving toward 203.0.113.1 are evaluated.

Verify:

R1# show access-lists 101
Extended IP access list 101
    10 permit tcp 192.168.1.0/24 any eq 80
    20 permit tcp 192.168.1.0/24 any eq 443
    30 permit tcp 192.168.2.0/24 any eq 80
    40 permit tcp 192.168.2.0/24 any eq 443
    50 permit icmp 192.168.3.0/24 any
    60 deny tcp any any eq 22
    70 permit ip any any
R1# show ip interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
  Internet address is 10.10.10.1/24
  IP access list is 101 (out)

Tip: In production, placing ACLs as close to the source as possible reduces unnecessary transit of denied packets across the network.

Task 2 Solution: Configure ACL 102 on R2 to block internal SSH between VLANs

What we are doing: Prevent SSH (TCP/22) directly between the Sales and Engineering VLANs by denying traffic both ways. We apply ACL 102 inbound on R2 Gi0/1 (the interface toward local switches/hosts).

R2# configure terminal
R2(config)# access-list 102 deny tcp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 eq 22
R2(config)# access-list 102 deny tcp 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 22
R2(config)# access-list 102 permit ip any any
R2(config)# interface GigabitEthernet0/1
R2(config-if)# ip access-group 102 in
R2(config-if)# end

What just happened:

• access-list 102 deny tcp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 eq 22 — denies SSH from Sales to Engineering.
• The reverse deny blocks SSH from Engineering to Sales.
• permit ip any any prevents the implicit deny from blocking all other intra-LAN traffic.
• Applying inbound on Gi0/1 stops SSH attempts as they enter R2 from the local switch, saving CPU and improving security segmentation.

Verify:

R2# show access-lists 102
Extended IP access list 102
    10 deny tcp 192.168.1.0/24 192.168.2.0/24 eq 22
    20 deny tcp 192.168.2.0/24 192.168.1.0/24 eq 22
    30 permit ip any any
R2# show ip interface GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
  Internet address is 10.10.40.1/24
  IP access list is 102 (in)

Real-world context: This is useful when you want to prevent lateral administrative access between user segments while allowing normal application traffic.

Task 3 Solution: Add logging for denied SSH attempts on R1

What we are doing: Edit the R1 ACL so the deny SSH entry logs matches. For numbered ACLs you usually recreate the ACL in the correct order; here we remove the old deny line and reinsert it with log.

R1# configure terminal
R1(config)# no access-list 101
R1(config)# access-list 101 permit tcp 192.168.1.0 0.0.0.255 any eq 80
R1(config)# access-list 101 permit tcp 192.168.1.0 0.0.0.255 any eq 443
R1(config)# access-list 101 permit tcp 192.168.2.0 0.0.0.255 any eq 80
R1(config)# access-list 101 permit tcp 192.168.2.0 0.0.0.255 any eq 443
R1(config)# access-list 101 permit icmp 192.168.3.0 0.0.0.255 any
R1(config)# access-list 101 deny tcp any any eq 22 log
R1(config)# access-list 101 permit ip any any
R1(config)# end

What just happened:

• We removed the original ACL and recreated it with the same permit lines plus deny tcp any any eq 22 log. The log keyword causes the router to generate syslog messages for each match — useful for security monitoring and incident response.
• Reapplying the ACL keeps the intended filtering but now provides visibility into blocked SSH attempts.

Verify:

R1# show access-lists 101
Extended IP access list 101
    10 permit tcp 192.168.1.0/24 any eq 80
    20 permit tcp 192.168.1.0/24 any eq 443
    30 permit tcp 192.168.2.0/24 any eq 80
    40 permit tcp 192.168.2.0/24 any eq 443
    50 permit icmp 192.168.3.0/24 any
    60 deny tcp any any eq 22 log
    70 permit ip any any

R1# show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
    Console logging: level informational, 256 message lines logged

Warning: Excessive logging on high-traffic devices can generate many messages. Use targeted logging or sampling in production.

---

Troubleshooting Scenario

Scenario: SSH to the internet still succeeds from PC1

Symptom: From PC1 (Sales subnet) you can still SSH to a public host despite the ACL. Your task: Find and fix the issue. Hint: ACL direction and interface placement matter.

Solution:

• Check show ip interface on R1 to ensure ACL 101 is applied outbound on Gi0/0:

R1# show ip interface GigabitEthernet0/0

• If it's not applied, apply it:

R1(config)# interface GigabitEthernet0/0
R1(config-if)# ip access-group 101 out

• Also ensure there are no other permit rules earlier in the ACL matching SSH (e.g., a mistakenly broad permit ip any any placed before the deny). If so, reorder ACL by removing and recreating with deny before the final permit.

---

Verification Checklist

• ACL 101 exists on R1 and contains web, icmp permit, ssh deny (with log), and final permit ip.
• ACL 101 is applied outbound on R1 GigabitEthernet0/0.
• ACL 102 exists on R2 and blocks SSH between 192.168.1.0/24 and 192.168.2.0/24.
• ACL 102 is applied inbound on R2 GigabitEthernet0/1.
• Denied SSH attempts are visible in R1 logs after generating test traffic.

Common Mistakes

Symptom	Cause	Fix
Web traffic blocked unexpectedly	permit ip any any placed before specific web permits (ACL order mistake)	Recreate ACL with specific permits first, general permit last
ACL has no effect	ACL not applied to correct interface/direction	Use show ip interface <int> and apply with ip access-group <num> in/out
Cannot edit numbered ACL line-by-line	Trying to use ip access-list commands on numbered ACL incorrectly	Remove and recreate numbered ACL with correct lines or use named ACLs for easier editing
Excessive syslog messages after enabling log	High rate of denied matches	Reduce logging scope, use sampling, or send logs to a remote collector

Challenge Task

Create a named extended ACL called CORP-INTERNET that:

• Allows only web (80/443), DNS (UDP 53), and HTTPS traffic from Sales and Engineering to the Internet.
• Allows SSH for a single management host (192.168.3.10) to the Internet.
• Denies all other outbound traffic and logs denied matches. Apply this ACL outbound on R1 Gi0/0. Do not use numbered ACLs — use named ACL configuration mode and justify the order of entries.