Access-Lists are fundamentals to today’s network as they provide basic packet filtering at the interface level. The router basically inspects each incoming or outgoing packet to determine whether to forward it or drop it per the configuration of the ACL (Access-List). While one of the many reasons to leverage the use of ACLs in today’s network is for security purposes, it is also important to know that there are two basic type of ACLs:

-Standard ACLs: Filters traffic based on source addresses – Typically applied closest to the destination
-Extended ACLs: Filters traffic based on source and destination addresses – Typically applied closest to the source

Today, we are going to focus on “Extended ACLs”. You can read about “Standard ACLs” here.

It’s important to note that Extended ACLs are generally applied closest to the source. In addition, extended ACLs are similar to Standard ACLs in terms of pure usage such as the “implicit deny” at the end,  the “Top to Bottom” order of operation but different from standard ACLs in a sense where extended ACLs can match on both source and destination addresses as well as protocol type such as tcp, gre, udp, icmp…

Let’s now hop onto the consoles and I’ll show you the steps needed to successfully configure an extended ACL. For the sake of this topic, we will use the following diagram…

Our main goal here is deny telnet from R1 to R2 and allow everything else which mean that even though we can’t telnet to R2 but we definitely should be able to ssh to R2.

All IP addressing scheme are pre-configured so let’s enable both telnet and ssh on R2. Let’s dive in now…

Very good ! Let’s now make a trip to R1 and make sure we can telnet and ssh to R2…

All right ! Looks like we can both telnet and ssh to R2 from R1 which is what we were looking for. Let’s now create extended ACLs on R1 to deny telnet traffic from R2.

Note that we could do it the other way around where R2 deny telnet packet in the inbound direction. But in this example, even though we are sourcing the telnet session we will still deny telnet packets in the inbound direction. Let’s dive in to R1…

Here, notice how the extended ACLs range is from 100 to 199. We then had to either deny or permit a specific range and in our case we denied 10.1.12.0/24 to any addresses. Note that the wilcard bits is used here instead of the subnet mask.

Bonus: The easiest way to calculate the wilcard bits is by subtracting the subnet mask from “255 255 255 255” as such:

255.255.255.255
–
255.255.255.0

0.0.0.255

Notice how also we have the command “eq telnet” which matches on the port number. We are saying block traffic from 10.1.12.0/24 on port 23 with the destination of “any” addresses. We then configure a permit all statement which comes before the “implicit deny” statement and allow things like icmp, ssh and so on…

Our next step is to now apply to the interface facing R2 in the ingress direction. Note that the ACL would not work if not tied to an interface here. Let’s do that…

Very good ! We’ve tested earlier that both telnet and ssh worked. If all is well in our configuration here, telnet should not be working anymore but any other traffic should be allowed. Let’s first start an icmp debug on R1 and test…

Excellent ! Here we can clearly see that ssh is in fact allowed and telnet has been blocked due to the extended ACL applied on the eth1/0 interface.

By running the command “sh ip access-lists”, we can clearly see here the matches on the ACLs.

That’s all I have for this topic. If you enjoyed it please leave a comment.