Cisco ACL network security lab with standard, extended, reflexive and time-based ACLs.
This repository documents a controlled Cisco ACL network security lab built in GNS3.
The lab was completed as part of my networking and security studies at Folkuniversitetet and focused on using Cisco Access Control Lists to control, restrict, test, and verify network traffic.
The goal of this lab was to understand how Cisco ACLs can be used as a basic but important network security control.
The lab focused on:
- Standard ACLs
- Extended ACLs
- Named ACLs
- ACL placement and direction
- Traffic filtering
- HTTP and HTTPS allow rules
- Blocking unwanted traffic
- Reflexive ACLs
- Time-based ACLs
- Logging and verification
- Security testing with Kali Linux
The lab was built in GNS3 using a virtual routed network.
Main components:
- Cisco vIOS routers
- Kali Linux test machine
- VPC client nodes
- Firefox client
- Ethernet switch
- NAT node representing internet access
- Cisco IOS CLI
- Nmap
- hping3
The topology included internal client networks, routed segments, and a NAT-connected internet-facing path.
The purpose was to test how ACLs behave when placed at different points in the network and how filtering decisions affect traffic between clients, routers, and internet access.
- Basic routed GNS3 topology
- IP addressing for routers and clients
- Routing between network segments
- Standard ACL to block traffic from a specific host
- Extended ACL to allow only selected outbound traffic
- HTTP and HTTPS permit rules
- Default deny behavior for unwanted traffic
- Named extended ACLs
- Logging for blocked traffic
- Reflexive ACL behavior for return traffic
- Time-based ACL rules using a defined time range
A standard ACL was used to block traffic from a specific host while allowing other traffic.
The test verified that:
- Local connectivity could still work where expected
- Traffic from the blocked host was denied
- Other hosts were still allowed
- ACL counters showed rule matches
An extended ACL was used to allow only specific types of traffic toward the internet.
The policy allowed:
- HTTP traffic
- HTTPS traffic
Other unwanted traffic was blocked.
The test verified that web access could work while other traffic types, such as ping or unsupported protocols, were denied.
Security testing was performed from Kali Linux in the controlled lab environment.
The tests included:
- Nmap scanning
- SYN traffic testing
- hping3 traffic generation
- Verification of blocked traffic
- Router ACL counter checks
- Basic CPU and network behavior observation
The lab also included more advanced ACL concepts.
Reflexive ACLs were used to allow return traffic for sessions initiated from the inside network without permanently opening broad inbound access.
Time-based ACLs were tested to control access depending on a defined schedule, such as allowing or blocking traffic during specific hours.
This lab helped me understand:
- How ACLs control traffic in routed networks
- The difference between standard and extended ACLs
- Why ACL placement and direction matter
- How implicit deny affects traffic
- How to verify ACL behavior using counters and tests
- Why logging is important for troubleshooting and incident analysis
- How reflexive ACLs can improve basic traffic control
- How time-based ACLs can support business-driven access policies
- Why ACLs are useful but should not replace dedicated firewalls in larger environments
- GNS3
- Cisco vIOS
- Cisco IOS CLI
- Access Control Lists
- Standard ACLs
- Extended ACLs
- Named ACLs
- Reflexive ACLs
- Time-based ACLs
- Kali Linux
- Nmap
- hping3
- NAT
- Routing
- TCP/IP
- Traffic filtering
- Network troubleshooting
This repository contains only sanitized documentation.
It does not include full router configurations, real credentials, sensitive addresses, raw logs, packet captures, or attack output.
Completed as a lab project during my networking and security studies.