Access Control List Lab

Configure and Modify Standard IPv4 ACLs

Configure and Modify Standard IPv4 ACLs – Cisco Packet Tracer Lab

This lab demonstrates my ability to plan, configure, verify, and modify standard numbered and named IPv4 access control lists (ACLs) in a simulated enterprise network. Using best practices, I applied ACLs to control traffic between LAN segments and across routers while adapting to evolving business requirements.

Objectives

  • Verify baseline connectivity between devices before applying ACLs

  • Configure both numbered and named standard ACLs

  • Apply ACLs to the correct interfaces and directions

  • Use wildcard masks to define matching criteria

  • Modify an existing ACL to reflect a policy change

  • Test and verify access control results

Network Overview

The network contains three routers (R1, R3, and Edge), four switches (S1–S4), and multiple PCs, simulating a small enterprise layout. All routers are pre-configured with IP addresses and routing using EIGRP. ACLs are applied only to R1 and R3 as part of the internal policy enforcement; the ISP-owned Edge router is not modifiable.

Part 1: Baseline Connectivity

Before applying any ACLs, I verified full connectivity across all devices using ping tests.

  • PC-A was able to ping both PC-C and PC-D

  • R1 successfully pinged PC-C and PC-D

  • PC-C was able to ping PC-A and PC-B

  • R3 successfully pinged PC-A and PC-B

  • All PCs were able to reach the external server at 209.165.200.254

This ensured the network was functioning correctly before applying traffic filtering.

Part 2: Configure and Verify Standard Numbered and Named ACLs

Step 1: Numbered Standard ACL on R3

Policy: Allow only traffic from 192.168.10.0/24 and 192.168.20.0/24 to access the 192.168.30.0/24 network. Deny all others.

Configuration:

R3(config)# access-list 1 remark Allow R1 LANs Access R3(config)# access-list 1 permit 192.168.10.0 0.0.0.255 R3(config)# access-list 1 permit 192.168.20.0 0.0.0.255 R3(config)# access-list 1 deny any

Applied to:

  • R3 interface g0/0/0 (facing the 192.168.30.0 LAN)

  • Direction: out

R3(config)# interface g0/0/0 R3(config-if)# ip access-group 1 out

Verification:

R3# show access-lists 1 R3# show ip interface g0/0/0

Results:

  • Ping from PC-A and PC-B to PC-C succeeded

  • Ping from PC-D to PC-C was denied (as expected)

  • Ping from R1 to PC-C also failed, proving ACL effectiveness

Step 2: Named Standard ACL on R1

Policy:

  • Permit PC-C (192.168.30.3) to access the 192.168.10.0/24 network

  • Permit the entire 192.168.40.0/24 network to access the same

  • All other access should be denied (added later)

Configuration:

R1(config)# ip access-list standard BRANCH-OFFICE-POLICY R1(config-std-nacl)# permit host 192.168.30.3 R1(config-std-nacl)# permit 192.168.40.0 0.0.0.255

Applied to:

  • R1 interface g0/0/0 (LAN interface toward 192.168.10.0/24)

  • Direction: out

R1(config)# interface g0/0/0 R1(config-if)# ip access-group BRANCH-OFFICE-POLICY out

Verification:

R1# show access-lists R1# show ip interface g0/0/0

Test Results:

  • PC-C was able to ping PC-A (allowed by ACL)

  • Extended ping from R3 using 192.168.30.1 as source to PC-A failed (denied as intended)

  • PC-D successfully pinged PC-A (allowed by the second rule)

Part 3: Modify a Standard Named ACL

New Requirement: Allow return traffic from the 209.165.200.224/27 network to access 192.168.10.0/24. An explicit deny any must also be added to follow consistent policy.

Modification Using Line Numbers:

R1(config)# ip access-list standard BRANCH-OFFICE-POLICY R1(config-std-nacl)# 30 permit 209.165.200.224 0.0.0.31 R1(config-std-nacl)# 40 deny any

Verification:

R1# show access-lists

Results:

  • PC-A was now able to successfully ping the external server at 209.165.200.254

  • ACL match counters confirmed the correct lines were triggered

Final ACL: BRANCH-OFFICE-POLICY

Standard IP access list BRANCH-OFFICE-POLICY 10 permit 192.168.30.3 20 permit 192.168.40.0 0.0.0.255 30 permit 209.165.200.224 0.0.0.31 40 deny any

No reapplication of the ACL was needed, as modifications took effect in-place.

Reflection

Why Use Extended ACLs?
Standard ACLs only filter based on source IP. Extended ACLs allow filtering based on source and destination IPs, protocols, and port numbers. They are useful when you need precise control over specific services like HTTP, FTP, or ICMP.

Why Use Named ACLs Over Numbered ACLs?
Named ACLs are easier to manage and update. They support line numbers and remarks, allowing clearer documentation and easier modification. This is especially valuable in large or frequently changing networks.

Skills Demonstrated

  • Creation of both numbered and named standard IPv4 ACLs

  • Use of wildcard masks to define source networks

  • Proper ACL interface placement and direction

  • Modification of ACLs in-place using line numbers

  • Verification using show access-lists and show ip interface