NHPREP — Hands-On CCNA, CCNP, CCIE Labs & Networking Courses

Lab Objectives

Configure extended access control lists (ACLs) to filter traffic by protocol and port.
Apply ACLs on the edge router to control HTTP, HTTPS, SSH, ICMP, and DNS flows.
Verify ACL behavior with show and basic connectivity tests.

ASCII Topology (use this exact topology)

                [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

IP Networks used in this lab (exact)

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

Tip: Think of an extended ACL like a bouncer that inspects the protocol and the exact port — not just the IP addresses. You can permit HTTP (tcp/80) while denying SSH (tcp/22) for the same source network.

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: Allow Web Only from Engineering

Create an extended ACL on R1 that permits HTTP (TCP/80) and HTTPS (TCP/443) traffic from the Engineering network (192.168.2.0/24) to any destination and denies other TCP traffic from that subnet. Apply the ACL where traffic leaves the enterprise towards the Internet.

Task 2: Permit SSH Only from Management

Permit SSH (TCP/22) originating from the Management network (192.168.3.0/24) to any remote host, but deny SSH from other internal networks. Continue to allow ICMP and DNS as needed for basic reachability. Apply the ACL on the router interface facing the Internet.

Task 3: Allow DNS for Sales Only

Allow DNS (UDP port 53) queries from Sales (192.168.1.0/24) to the Internet, but block all other services from Sales to external destinations. Apply and test the ACL.

Think About It: Why must the ACL be applied closest to the traffic's source when you want to prevent undesired traffic from traversing the network? What happens if you apply it at the destination instead?

Lab Solution

Task 1 Solution: Allow Web Only from Engineering

What we are doing: Build an extended ACL (number 110) that explicitly permits HTTP and HTTPS from 192.168.2.0/24 and blocks other TCP from that subnet. We apply it outbound on R1's Gi0/0 interface (the link toward the Internet) so only allowed web traffic leaves the network.

! Create the extended ACL permitting web for Engineering
access-list 110 permit tcp 192.168.2.0 0.0.0.255 any eq 80
access-list 110 permit tcp 192.168.2.0 0.0.0.255 any eq 443
! Permit ICMP and DNS generally so basic services continue working
access-list 110 permit icmp any any
access-list 110 permit udp any any eq 53
! Deny remaining IP traffic and log hits for visibility
access-list 110 deny ip 192.168.2.0 0.0.0.255 any log
access-list 110 permit ip any any
!
! Apply ACL outbound on the interface toward the Internet
interface Gi0/0
 ip access-group 110 out

What just happened:

access-list 110 permit tcp 192.168.2.0 0.0.0.255 any eq 80 — Allows HTTP from Engineering to anywhere (inspects protocol tcp and destination port 80). This ensures web browsing works.
... eq 443 — Same for HTTPS (secure web).
permit icmp any any — Allows ICMP for ping/troubleshooting network-wide.
permit udp any any eq 53 — Allows DNS lookups (UDP port 53) to public DNS servers.
deny ip 192.168.2.0 0.0.0.255 any log — Explicitly blocks all other traffic from Engineering to external destinations and logs matches. Placing this deny before a final permit ensures only the intended traffic is allowed.
permit ip any any — Keeps traffic from other networks unaffected (you might prefer more selective rules in production).

Verify:

R1#show access-lists 110
Extended IP access list 110
    10 permit tcp 192.168.2.0/24 any eq 80
    20 permit tcp 192.168.2.0/24 any eq 443
    30 permit icmp any any
    40 permit udp any any eq 53
    50 deny ip 192.168.2.0/24 any (log)
    60 permit ip any any

Real-world note: In production you often avoid a broad permit ip any any unless another device enforces segmentation. You could instead write explicit permits for each trusted subnet.

Task 2 Solution: Permit SSH Only from Management

What we are doing: Allow SSH from Management (192.168.3.0/24) and deny SSH from other internal networks. We'll place the rule in the same extended ACL (110) on R1 for simplicity; SSH permits are added before the Engineering deny so both sets of rules coexist.

! Add SSH permit for Management
access-list 110 permit tcp 192.168.3.0 0.0.0.255 any eq 22
! (Existing deny and permits remain in place)

What just happened:

The new line allows TCP port 22 (SSH) from Management to any external host. Because ACLs are processed top-down, add this permit before any deny that might catch 192.168.3.0/24 traffic.

Verify:

R1#show access-lists 110
Extended IP access list 110
    10 permit tcp 192.168.2.0/24 any eq 80
    20 permit tcp 192.168.2.0/24 any eq 443
    30 permit icmp any any
    40 permit udp any any eq 53
    45 permit tcp 192.168.3.0/24 any eq 22
    50 deny ip 192.168.2.0/24 any (log)
    60 permit ip any any

To test from R1 (or an internal host that can reach the Internet simulation):

! From a router that can source a Management address (example):
R3#telnet 203.0.113.1 22

Expected: If sourced from 192.168.3.0/24, the SSH connection should be permitted; if from 192.168.2.0/24 it should be denied.

Task 3 Solution: Allow DNS for Sales Only

What we are doing: Ensure Sales (192.168.1.0/24) can perform DNS queries to the Internet, but block other services from Sales to external networks.

! Permit DNS for Sales
access-list 110 permit udp 192.168.1.0 0.0.0.255 any eq 53
! Explicitly deny other IP traffic from Sales to the Internet
access-list 110 deny ip 192.168.1.0 0.0.0.255 any log

What just happened:

permit udp 192.168.1.0 0.0.0.255 any eq 53 — Lets Sales perform DNS lookups over UDP. Many DNS queries use UDP; for robustness you could also permit TCP/53 if large responses or zone transfers are expected.
deny ip 192.168.1.0 0.0.0.255 any log — Blocks other outbound services from Sales.

Verify:

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

Try a DNS query test from a Sales host (PC1):

Expected: DNS queries succeed. Attempts to access web servers (HTTP/HTTPS) from Sales to Internet are blocked.

Troubleshooting Scenario

Scenario: Sales cannot browse web but DNS works

Symptom: PC1 (Sales) can resolve names but cannot open websites in browser (HTTP/HTTPS).

Your task: Find and fix the issue.

Hint: Look at the order of ACL entries and any deny statements that may pre-empt permits.

Solution:

Use show access-lists 110 to confirm a deny ip 192.168.1.0/24 any exists before any later permit for web.
Fix by inserting a specific permit for HTTP/HTTPS for Sales if web should be allowed, or move the deny after desired permits. Example fix:

! Permit web for Sales (if intended)
access-list 110 permit tcp 192.168.1.0 0.0.0.255 any eq 80
access-list 110 permit tcp 192.168.1.0 0.0.0.255 any eq 443
! Keep deny after these permits

Explanation: ACLs are evaluated top-to-bottom. A deny earlier will block traffic even if a later permit would match.

Warning: Using wide deny ip entries without careful ordering can unintentionally block legitimate services.

Verification Checklist

ACL 110 configured with permits for Engineering web, Management SSH, Sales DNS.
ACL applied outbound on R1 Gi0/0.
show access-lists displays expected entries and hit counts.
From Engineering host: web (TCP 80/443) works; other services blocked.
From Management host: SSH to Internet permitted; others as configured.
From Sales host: DNS works; other services blocked as intended.

Common Mistakes

Symptom	Cause	Fix
Web still blocked for Engineering	`deny ip 192.168.2.0/24 any` placed above permit entries	Reorder ACL: put permits before deny or insert specific permits above deny
No logging or visibility	`log` keyword omitted on deny lines	Add `log` to deny lines to see matches in syslog
ACL not taking effect	ACL not applied to correct interface or direction	Ensure `ip access-group 110 out` on Gi0/0 (toward Internet)
Management SSH blocked unexpectedly	A broader deny for 192.168.3.0/24 exists earlier	Verify ordering; add explicit permit before deny

Challenge Task

Create a single extended ACL that: permits only HTTP and HTTPS from Engineering (192.168.2.0/24), permits only DNS (TCP/UDP 53) from Sales (192.168.1.0/24), permits SSH from Management (192.168.3.0/24), denies all other traffic from these three subnets to the Internet, and logs denied matches. Apply it outbound on R1 Gi0/0. Do this without step-by-step guidance.

Final thought: Apply ACLs as close to the traffic source as possible to conserve network resources — this prevents undesired traffic from traversing the network unnecessarily.

Filtering by Protocol and Port

Lab Objectives

Lab Tasks (Try It Yourself First!)

Task 1: Allow Web Only from Engineering

Task 2: Permit SSH Only from Management

Task 3: Allow DNS for Sales Only

Lab Solution

Task 1 Solution: Allow Web Only from Engineering

Task 2 Solution: Permit SSH Only from Management

Task 3 Solution: Allow DNS for Sales Only

Troubleshooting Scenario

Scenario: Sales cannot browse web but DNS works

Verification Checklist

Common Mistakes

Challenge Task