Lab 11: Cisco Access List - AidanP017/Aidan-NET-330 GitHub Wiki
Purpose
In this lab, we used Cisco Packet Tracer to practice using standard and extended named access lists in a workspace.
Creation of the Standard ACL on R3
To start, we created a standard Access Control List (ACL) on the R3 router. This ACL will be applied inbound and block traffic from the 192.168.11.0/24 network from accessing local networks on the R3 router.
On R3, create the standard ACL as follows:
In the screenshot above, a standard ACL named STND-1 is created. It is also configured to deny any packets with a source address of 192.168.11.0/24 but permit all other traffic.
Then, we applied the ACL as a filter on packets entering R3 through the serial port of 0/0/0. Since this ACL is being applied for inbound, the word in will be specified at the end of the below command.
If configured successfully, it should not be possible to ping PC5 from PC3 due to the ACL blocking traffic from the 192.168.11.0/24 network.
Save the configuration on R3 before moving on.
Creation of the Extended ACL on R2
Next, we created an extended ACL on the R2 router that would be used to block traffic originating from any device on the 192.168.10.0/24 network to access the 200.200.200.1 host. This ACL would also be applied for outbound traffic on the router's serial port of 0/0/0.
In the screenshot below, an extended ACL named EXTEND-1 is created on R2. It is configured to deny traffic from the 192.168.10.0/24 network to the host but permit all other traffic.
Then, we applied the ACL as a filter on packets leaving R2 through the serial port of 0/0/0. Since this ACL is being applied for outbound, the word out will be specified at the end of the command below.
If configured successfully, it should not be possible for PC1 to ping 200.200.200.1 due to traffic from the 192.168.10.0/24 network being filtered when the destination is 200.200.200.1.
However, all other pings from PC1 should remain successful.
Save the configuration on R2 before moving on.
Bonus Tasks
Two bonus tasks were performed that involved the creation of two more extended ACLs on the R1 router.
Creation of Extended ACL for File Server on R1
First, we created an extended ACL on R1 that would deny all access from the ISP (200.200.200.0/24) to the File Server host (192.168.20.210) and allow access from any other device.
Then, we applied the ACL to outbound traffic on FastEthernet0/0 going towards the 192.168.20.0/24 network.
If configured successfully, it should not be possible for the ISP router to access the File Server. However, all other traffic should be permitted.
Creation of Extended ACL for Web Server on R1
For the second extended ACL on R1, this would only allow web access to the Web Server on 192.168.20.201. Ports 80 and 443 are specified to permit HTTP and HTTPS connections to the Web Server from a browser.
Then, we applied the ACL to outbound traffic on FastEthernet0/0 similar to the first bonus task.
If configured successfully, it should not be possible to ping the Web Server from PCs in the workspace.
However, it should be possible for PCs to access the Web Server by accessing it in the browser.
Make sure to save the configurations.
Using the command show access-lists
on the routers will allow you to see the access lists that have been created and configured.
Troubleshooting
Originally, I ran into an issue with the second bonus task. After creating the ACL, I was not able to ping the Web Server from the terminal of PCs as intended. However, I could not access the Web Server from the browser.
I recalled that the order in which permissions and denials are defined in an ACL are very important; otherwise, you would have to restart the configuration process. I recreated the ACL with a different order with regards to permissions and denials. I specified the permissions for access to the Web Server through the browser first, then I denied access to all hosts. Finally, I allowed all other traffic to the Web Server. The final configuration looked like this:
Although the configurations in my previous attempt included the same commands, I entered in the "deny" commands before any of the "permit" commands. The permit ip any any
is correct as the last command regardless, but I needed to permit access to the Web Server through the browser so that was established and then deny access from all hosts in any other form. This troubleshooting process fixed my configuration and allowed me to complete the task.