An access control list (ACL) is a sequence of conditions or statements that can match packets moving through the network. You can do quite a few things with packets matched by ACLs. However, CCNA exams tend to focus on the most common use of ACLs as traffic filters. In this article, we provide a quick introduction to ACLs before moving on to their configuration and verification. The article is part of the GNS3 Labs for CCNA series, and just like other pieces in the series, we provide GNS3 topology and initial configuration files as a free download. We assume you already have GNS3 installed but you may refer to GNS3 Labs for CCNA: Getting Started if you need help setting up GNS3. You may also refer to GNS3 Labs for CCNA: DHCP Server Configuration and Verification if you need help setting up hosts in GNS3, even if you are not interested in DHCP.

Introduction to ACLs

Access control lists perform packet filtering to control which packets can reach which area of the network. Such control can restrict access of users and hosts to parts of the network, and provides a certain degree of security. All ACLs fall into one of two categories: standard or extended. A standard ACL can filter only on the source address. If you intend to filter on anything other than the source address, an extended ACL is necessary. All ACLs, whether standard or extended, must be identified by a number or name. Different configuration commands are used to define numbered and named ACLs. The focus of this article is standard numbered IPv4 access control lists. Standard ACLs were initially numbered only 1 to 99, but the range was later expanded to include number 1300 to 1999 as well.

If you do not configure ACLs on your router, all packets passing through the router could reach all parts of your network. An ACL can let one host access a part of the network yet prevent another host from accessing the same area. ACLs are often placed in routers at the boundary of your internal network and an external network such as the Internet. You can configure ACLs on an interface directly in the forwarding path of packets so that inbound traffic or outbound traffic or both are filtered. Once the access list is enabled, it will scrutinize each IPv4 packet passing through the interface in a specified direction, either allowing or discarding the packet.

Standard numbered IPv4 ACLs are created with following the global configuration command:

access-list {1-99 | 1300-1999} {permit | deny} matching-parameters

Each standard numbered ACL has one or more access-list commands with the same number form the 1-99 or 1300-1999 range. You can pick absolutely any number from the allowed range for a standard ACL. Each access-list statement also has the permit or deny keyword to specify the action to be taken when a packet matches the statement. Besides the ACL number and action, you have to specify the source IPv4 address, or a range of source IPv4 addresses using a wildcard mask. The wildcard is a playing card that can have any value, suit, or color in a game at the discretion of the player holding it. In a similar way, the wildcard mask tells Cisco IOS Software to ignore portions of the address when matching packets. Wildcard masks, just like IPv4 addresses, are written as four decimal numbers, each representing an octet, separated by periods. The router must match an octet if the corresponding octet of wildcard mask is decimal 0. The router must ignore an octet, considering it already matched, if the corresponding octet of the wildcard mask is decimal 255.

An ACL has one or more statements and each packet is compared against each of the statements in order, until there is a match or the end of ACL is reached. Once a packet matches a statement in the ACL, the router takes the permit/deny action and stops looking further in the ACL.

Configuration of Basic ACLs

We are going to use the network shown in the graphic below to perform ACL configuration and verification. You may download the GNS3 topology and initial configuration files, if you haven’t done that yet. The initial configuration files already have IP addressing and static routing configured. However, you still have to configure Linux Micro Core hosts A, B, C, and Server. We will come to that in a while.

FastEthernet0/0 of R2 is connected to the secure network that houses Server
A, B, and C are all connected to R1 in the insecure part of network. In other words, everything to the left of R2 is insecure while everything on its right is secure. We are going to configure an access control list on R2 and apply it inbound to Serial0/0 for controlling which hosts are allowed to access Server and which hosts are denied access.

We have to perform a few tasks to configure persistent IPv4 addresses on hosts. This is a one-time task and the settings will be available every time you load the GNS3 topology later.

You have to go to the CLI (command-line interface) of host A and enter vi /opt/bootlocal.sh to launch the vi editor. The vi is not the easiest of Linux editors, but that’s the only choice we have on Micro Core. You have to press i and then scroll down to the end of file and add the lines given below:

hostname A
ifconfig eth0 172.16.1.2 netmask 255.255.255.0 up
route add default gw 172.16.1.1

Once done, you have to enter the Esc key and then enter the sequence :wq to save the changes and quit vi. In the end, enter the /usr/bin/filetool.sh -b command.

You have to perform the same steps on B, C, and Server one by one, adding relevant configuration lines per below details:

B:

hostname B
ifconfig eth0 172.16.1.3 netmask 255.255.255.0 up
route add default gw 172.16.1.1

C:

hostname C
ifconfig eth0 172.16.2.2 netmask 255.255.255.0 up
route add default gw 172.16.2.1

Server:

hostname Server
ifconfig eth0 172.16.3.2 netmask 255.255.255.0 up
route add default gw 172.16.3.1

You should be able to successfully ping Server IPv4 address 172.16.3.2 from A, B, and C without any restrictions.

tc@A:~$ ping 172.16.3.2 -c 3
PING 172.16.3.2 (172.16.3.2): 56 data bytes
64 bytes from 172.16.3.2: seq=0 ttl=62 time=23.005 ms
64 bytes from 172.16.3.2: seq=1 ttl=62 time=15.668 ms
64 bytes from 172.16.3.2: seq=2 ttl=62 time=24.144 ms
— 172.16.3.2 ping statistics —
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 15.668/20.939/24.144 ms
tc@B:~$ ping 172.16.3.2 -c 3
PING 172.16.3.2 (172.16.3.2): 56 data bytes
64 bytes from 172.16.3.2: seq=0 ttl=62 time=42.360 ms
64 bytes from 172.16.3.2: seq=1 ttl=62 time=22.083 ms
64 bytes from 172.16.3.2: seq=2 ttl=62 time=21.880 ms
— 172.16.3.2 ping statistics —
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 21.880/28.774/42.360 ms
tc@C:~$ ping 172.16.3.2 -c 3
PING 172.16.3.2 (172.16.3.2): 56 data bytes
64 bytes from 172.16.3.2: seq=0 ttl=62 time=50.152 ms
64 bytes from 172.16.3.2: seq=1 ttl=62 time=24.860 ms
64 bytes from 172.16.3.2: seq=2 ttl=62 time=18.181 ms
— 172.16.3.2 ping statistics —
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 18.181/31.064/50.152 ms

We want to be able to control which hosts on the left can reach Server. We are going to use a standard numbered ACL to exercise the control we want. The access list will be created by entering the following lines on R2, in global configuration mode:

access-list 1 permit 172.16.1.2
access-list 1 deny 172.16.1.0 0.0.0.255
access-list 1 permit 172.16.2.0 0.0.0.255

Please note that the above lines are not part of the initial configuration. However, you can simply cut and paste the lines to R2, in global configuration mode. The first statement matches and permits packets with source IPv4 address of 172.16.1.2 only. The second statement matches and denies packets with source IPv4 address from the 172.16.1.0/24 subnet. The third and last statement matches and permits packets with source IPv4 address from the 172.16.2.0/24 subnet.

You can verify that the ACL was successfully created using show access lists command:

R2#show ip access-lists
Standard IP access list 1
10 permit 172.16.1.2
20 deny 172.16.1.0, wildcard bits 0.0.0.255
30 permit 172.16.2.0, wildcard bits 0.0.0.255

The access list will have no effect as it is not applied to an interface yet. You can verify if an ACL is applied to an interface by using the show ip interface command:

R2#show ip interface serial0/0
Serial0/0 is up, line protocol is up
Internet address is 172.16.12.2/30
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Outgoing access list is not set
Inbound access list is not set

We are now going to apply the ACL using ip access-group command in interface configuration mode. Please note the in keyword used to apply the ACL inbound to examine packets wanting to enter R2 through Serial0/0.

interface Serial0/0
ip access-group 1 in

You may run the show ip interface command again at this point.

R2#show ip interface serial0/0
Serial0/0 is up, line protocol is up
Internet address is 172.16.12.2/30
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Outgoing access list is not set
Inbound access list is 1

<Some output omitted>

You may try to ping Server IPv4 address 172.16.3.2 from A, B, and C again.

tc@A:~$ ping 172.16.3.2 -c 3
PING 172.16.3.2 (172.16.3.2): 56 data bytes
64 bytes from 172.16.3.2: seq=0 ttl=62 time=68.744 ms
64 bytes from 172.16.3.2: seq=1 ttl=62 time=29.836 ms
64 bytes from 172.16.3.2: seq=2 ttl=62 time=18.373 ms
— 172.16.3.2 ping statistics —
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 18.373/38.984/68.744 ms
tc@B:~$ ping 172.16.3.2 -c 3
PING 172.16.3.2 (172.16.3.2): 56 data bytes
— 172.16.3.2 ping statistics —
3 packets transmitted, 0 packets received, 100% packet loss
tc@C:~$ ping 172.16.3.2 -c 3
PING 172.16.3.2 (172.16.3.2): 56 data bytes
64 bytes from 172.16.3.2: seq=0 ttl=62 time=70.327 ms
64 bytes from 172.16.3.2: seq=1 ttl=62 time=29.945 ms
64 bytes from 172.16.3.2: seq=2 ttl=62 time=17.609 ms
— 172.16.3.2 ping statistics —
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 17.609/39.293/70.327 ms

The ping results confirm that A, and C can reach Server while B cannot, as expected.

If you create an access list but it appears to be doing nothing, you should first check if it has been applied to the right interface in the right direction. It is very tempting to display the running configuration to troubleshoot ACLs (and everything else), but it is more effective to use show commands. The time and effort you spend learning the various Cisco IOS show commands make you more efficient at network troubleshooting, in the long run.

We have reached the conclusion of the article but our coverage of access control lists is not complete. We will follow up with GNS3 Labs for CCNA: Advanced Access Control Lists to cover advanced features of ACLs relevant to the new CCNA version 2 exams.