access-lists-featured-image

CCNA Lab: Standard and Extended ACLs (IPv4)

Cisco, Guides, Labs /

Lab Overview

Access Control Lists (ACLs) are a critical part of any network topology and are fundamental to ensuring proper access control to network resources. We’ll take a look out both Standard and Extended ACLs and best practice on where to place them in a network topology.

In this lab, we take a look at the following:

I have provided free packet tracer labs to go along with this guide. Everything necessary to complete the lab has already been configured, except for the ACLs. It is your job to configure ACLs and place them in the most efficient locations while also satisfying the specified rules.

What are Access Control Lists (ACLs)?

At their core, ACLs are simply a way to identify traffic. It is how you apply an ACL to determine its effect on a network. They can be used to control whether or not a router forwards or drops a packet depending on the information found in the packet header. ACLs are primarily used for security purposes – such as limiting or even preventing access to a network or network resources.

Standard vs. Extended ACLs

Standard ACLs are not very common today because they are very limited in what they can do. They can only filter traffic based on source IP addresses, which can be either be a single host, or a whole subnet. Standard ACLs are sometimes sufficient if an administrator or engineer is only concerned with filtering traffic based on source addresses.

Extended ACLs are way more flexible and can match many more things such as source and/or destination IP addresses, protocols, and port numbers. This allows administrators and engineers to customize how they want access control to work in their environment compared to standard ACLs. Extended ACLs are required if an administrator or engineer needs to filter traffic on anything more than a source address.

Named vs. Numbered ACLs

Numbered ACLs are simply ACLs that are tied to a number. They can be either standard or extended depending on the number:

  • 1-99 and 1300-1999 are for Standard ACLs
  • 100-199 and 2000-26999 are for Extended ACLs

Named ACLs are exactly what they suggest – ACLs with a named, which can include alphanumeric characters. These are great because you can use descriptive names for ACLs to help easily identify what they do.

ACL Placement

Determining where to place ACLs is also an important concept to understand. If you place an ACL in the wrong part of a network, it may cause unintended traffic flow issues.

First, let’s quickly take a look at Inbound vs. Outbound ACLs:

  • Inbound ACLs filter traffic coming into an interface before it gets processed. Traffic that matches the ACL gets discarded, and does not need to be processed for routing. These are generally more efficient and avoids wasting resources to process traffic that is doomed to be dropped anyway. If it is permitted, then it continues to be processed for routing.
  • Outbound ACLs process traffic for routing before being compared to an ACL. This means that even if the traffic matches a configured ACL, the device still processed it anyway, but drops it when it matches an ACL.

It’s important to keep these two methods in mind. They are also used to determine where to place an ACL. However, there are two key things to memorize best practice ACL placement:

Place standard ACLs as close to the destination as possible
Because standard ACLs only filer on source addresses, it is best to place them as close to the destination as possible. You want to do this to avoid restricting traffic from the source to other parts of the network that you did not intend.

Place extended ACLs as close to the source as possible
Extended ACLs can technically be placed anywhere since they use both source and destination addresses for filtering. However, it is generally best practice to place them as close to the source as possible. This means the traffic will be filtered as early as possible and avoids adding overheard to devices to process traffic that will be dropped anyway.

Configuring Standard ACLs

Let’s take a look at how to configure standard ACLs and where to place them. Below is the lab topology used in the provided packet tracer labs.

standard-acl-topology

Objectives:

  1. Create a numbered ACL “50” to satisfy the following rules:
    • Deny any devices in the 10.1.1.0 /24 network from accessing the 10.1.3.0 /24 network without disrupting access to the external PC.
    • Permit any other traffic
    • Place the ACL in best place in the topology
  2. Create a numbered ACL “60” to satisfy the following rules:
    • Deny PC2 from accessing the the 10.1.1.0 /24 network without disrupting access to the external PC.
    • Permit any other traffic
    • Place the ACL in best place in the topology
  3. Verify
    • Verify PC1 cannot ping PC4 (PC4 will not be able to ping PC1 due to ping replies being blocked by the ACL)
    • Verify PC2 cannot ping PC1, but PC3 can
    • Verify all PCs can ping the external PC
1. Configuring ACL 50

The first thing we need to do is determine which device the ACL needs to be configured on. Recall that it is best practice to place standard ACLs as close to the destination as possible. Since we are wanting to deny devices from accessing 10.1.3.0 /24, that would be the destination network. R3’s GigbitEthernet0/0 interface is the closest interface to that network, so we will configure the ACL on R3.

The syntax to create a numbered ACL is access-list {number} {action} {host/subnet} [wildcard].

access-list Command Syntax

Because we are wanting to filter out traffic from any device in the 10.1.1.0 /24 network, we will use the network address with a wildcard mask in the deny statement followed by a permit any, which will ensure any other traffic can access the 10.1.3.0 /24 network.

access-list 50 deny 10.1.1.0 0.0.0.255
access-list 50 permit any

As previously mentioned, R3’s GigabitEthernet0/0 interface is the closest to the destination network. This is the interface where we want the filtering to take place. To do that, we need to go into interface configuration mode with interface GigabitEthernet0/0 command, and enter the ip access-group 50 out command. This tells the device to apply the filter on traffic going outbound from the GigabitEthernet0/0 interface.

ip access-group Command syntax
interface GigabitEthernet0/0
  ip access-group 50 out

ACL 50 is now configured and placed correctly. You can use the show access-list command to verify your configuration.

2. Configuring ACL 60

We can use the same logic as ACL 50 to determine where to put ACL 60. In this case, R1’s GigabitEthernet0/1 interface is the closest interface to the destination network.

ACL 60 is a little different – we need to filter on a single host address rather than a network address with a wildcard mask, however the syntax is very similar:

access-list 60 deny host 10.1.2.10
access-list 60 permit any

Since we’ve already determined the interface to apply the filter to, all we need to do is apply the filter to outbound traffic:

interface GigabitEthernet0/1
  ip access-group 60 out
3. Verify

Now that both ACLs are configured and placed, let’s verify with a few ping tests.

Verify PC1 cannot ping PC4
This will verify that 10.1.1.0 /24 cannot reach the 10.1.3.0 /24 network. (ACL 50)

PC1 ping to PC4

Verify PC2 cannot ping PC1, but PC3 can
This verifies that ONLY PC2 cannot reach the 109.1.1.0 /24 network (ACL 60)

PC2 ping to PC1
PC3 ping to PC1

Verify all PCs can ping the External PC
This verifies that our ACL placement did not disrupt access to the external PC.

Configuring Extended ACLs

Let’s now take a look at how to configure extended ACLs, and where to place them. Below is the topology from the provided packet tracer lab. Recall that extended ACLs can filter on source and destination addresses, port numbers, and protocols. We will be using all three in this lab.

Objectives:

  1. Create a named, extended ACL called “extended_local_ACL” with the following rules:
    • Allow only PC1 to ping and browse to local_HTTP1 using HTTP and HTTPs.
    • Allow only PC2 to ping and browse to local_HTTP2 using HTTP and HTTPs.
    • Deny any hosts on the 10.1.1.0 /24 network from reaching the 172.16.1.0 /24 network.
    • Allow any hosts on the 10.1.1.0 /24 network to access any other network.
    • Bind extended_local_ACL to the most efficient interface on R1.
  2. Create a numbered, extended ACL with a number of “150” and apply the following rules:
    • Allow any hosts on the 10.1.1.0 /24 network to browse to external websites.
    • Allow any external hosts to browse to the internal HTTP servers on the 172.16.1.0 /24 network.
    • Deny external hosts from accessing the 10.1.1.0 /24 network.
  3. Verify
    • Verify PC1 can ping local_HTTP1, but not local_HTTP2.
    • Verify PC1 can browse to local_HTTP1 (via IP) with HTTP and HTTPs.
    • Verify PC2 can ping local_HTTP2, but not local_HTTP1
    • Verify PC2 can browse to local_HTTP2 (via IP) with HTTP and HTTPs
    • Verify PC1. PC2, and PC3 can all browse to nickm155.sg-host.com and cisco.com
1. Configuring extended_local_ACL

Since R1 is the only router in the topology, let’s focus on configuring the ACL before determining where to apply it. To create a named, extended ACL use the ip access-list {standard/extended} {number/name} command. This will enter into an ACL configuration mode, where you can add permit and deny statements.

Note: You can also use this command to create standard, named ACLs. This guide does not use standard, named ACLs.

ip access-list Command Syntax

Let’s use the ip access-list extended extended_local_ACL command to create the ACL and enter ACL configuration mode. 

R1(config)#ip access-list extended extended_local_ACL
R1(config-ext-nacl)#

From there, we can take a look at how to do use permit and deny statements. The syntax to use permit/deny statements is permit/deny {protocol} {source} {destination} {port #}.

permit/deny Statement Command Syntax

Let’s configure the first three permit statements bullet one of the objectives: Allow only PC1 to ping and browse to local_HTTP1 using HTTP and HTTPS.

R1(config-ext-nacl)# permit icmp host 10.1.1.1 host 172.16.1.3
R1(config-ext-nacl)# permit tcp host 10.1.1.1 host 172.16.1.3 eq 80
R1(config-ext-nacl)# permit tcp host 10.1.1.1 host 172.16.1.3 eq 443

Notice how the port number is specified in the permit statement. This tells the router to permit any TCP traffic with a port number of 80 and 443 (HTTP and HTTPS) with a source of 10.1.1.1 (PC1) and a destination of 172.16.1.3 (local_HTTP1). We can use the same syntax to add permit statements for PC2:

R1(config-ext-nacl)# permit icmp host 10.1.1.2 host 172.16.1.4
R1(config-ext-nacl)# permit tcp host 10.1.1.2 host 172.16.1.4 eq 80
R1(config-ext-nacl)# permit tcp host 10.1.1.2 host 172.16.1.4 eq 443

The next thing we need to do is deny any hosts on the 10.1.1.0 /24 network from reaching the 172.16.1.0 /24 network. This will ensure no other PCs (if there were any) can ping or browse to the local HTTP servers. We can specify the protocol as “ip” which will deny all IP traffic between 10.1.1.0 /24 and 172.16.1.0 /24, besides what’s been permitted.

R1(config-ext-nacl)# deny ip 10.1.1.0 0.0.0.255 172.16.1.0 0.0.0.255

Finally, all we need to do is allow any hosts on the 10-.1.1.0 /23 network to access any other network. Because there is an implicit deny any at the end of ACLs, this will ensure PC1 and PC2 can still access the internet. Similar to the previous statement, we can use “ip” to permit all IP traffic from 10.1.1.0 /24 to any other destination network.

R1(config-ext-nacl)# permit ip 10.1.1.0 0.0.0.255 any

Now that we have the ACL configured, we need to determine which interface to place it on. Remember, it is best practice to place extended ACLs as close to the source as possible. R1’s GigabitEthenet0/1 interface is the best place.

R1(config)#interface gigabitEthernet0/1
R1(config-if)#ip access-group extended_local_ACL in
2. Configuring extended ACL 150

The next ACL we’ll create is ACL 150. Notice how the number falls within the extended range (100-199 and 2000-26999) for numbered ACLs. We’ll use the access-list {number} {action} syntax.

This ACL will allow the 10.1.1.0 /24 network to browse to external websites. Recall that in the extended_local_ACL we added the permit ip 10.1.1.0 0.0.0.255 any statement to allow that network to access any other network. However, we have to allow traffic from external networks back into the network.

The first command we need to do is access-list 150 permit tcp any 10.1.1.0 0.0.0.255 established. This will allow any TCP connections originating from the inside network back into the network, hence the established keyword.

access-list 150 permit tcp any 10.1.1.0 0.0.0.255 established

Next, we need to permit any external HTTP and HTTPS traffic to access the local HTTP servers. Like before, we can use “eq” and specify ports 80 and 443.

access-list 150 permit tcp any 172.16.1.0 0.0.0.255 eq 80
access-list 150 permit tcp any 172.16.1.0 0.0.0.255 eq 443

You may not have caught it, but since we are creating an ACL with permit/deny statements, we need to be sure to include DNS in the equation. Otherwise, DNS traffic from the internal PCs will be dropped. The permit statement below allows DNS traffic (port 53) from the DNS server to reach the 10.1.1.0 /24 network.

access-list 150 permit udp host 173.20.1.1 eq 53 10.1.1.0 0.0.0.255

Finally, we can satisfy the last objective to deny external hosts from accessing the 10.1.1.0 /24 network with the below deny statement.

access-list 150 deny ip 173.20.1.0 0.0.0.255 10.1.1.0 0.0.0.255

The best place to apply this ACL is inbound on R1’s GigabitEthernet0/0 interface, which is the closest interface to the external network.

R1(config)# interface gigabitEtherne0/0
R1(config-if)# ip access-group 150 in
3. Verify

Now that both ACLs are configured and placed, let’s verify with some ping and browsing tests. You can use the show access-lists command to verify your configuration. You can also use this command to see ACL matches, which is super handy when verifying.

  • Verify PC1 can ping local_HTTP1, but not local_HTTP2.
  • Verify PC1 can browse to local_HTTP1 (via IP) with HTTP and HTTPS
  • Verify PC2 can ping local_HTTP2, but not local_HTTP1
  • Verify PC2 can browse to local_HTTP2 (via IP) with HTTP and HTTPS
  • Verify PC1. PC2, and PC3 can all browse to nickm155.sg-host.com and cisco.com

Thanks for Reading!

Thanks for checking out my guide on ACLs. If you believe there is something wrong with the initial configuration or have any suggestions/feedback, please contact me via my contact form to let me know.

Full Configuration

The full configurations for both labs can be found on my GitHub.

Leave a Comment

Your email address will not be published. Required fields are marked *