Cisco CCNA 200-301 – ACLs – Access Control Lists Part 2

4. ACL Syntax

In this lecture, you’ll learn about the syntax of our Access Control List commands and the meanings of the different options. So we go to Global Config to create an access list. Here we’ve said Access list 100. So as you learned in the last lecture, you know that this is going to be an extended ACL. Then if we use the context sensitive help up. So I’ve put in a question mark after that to see what my options are. I can deny or I can permit. I also get an option to put a remark in here as well. It’s a good idea to include remarks in your ACL.

This is because in production environments, the ACLs can get to be really long, and if somebody else comes in and looks at the ACL after you, it’s not going to be obvious what all the different lines are there for. For example, let’s say that currently you’ve got an extranet connection to a business partner, so you put a line in your ACL to permit that traffic. Well, maybe two years down the line, we’re not a business partner anymore, and if another administrator is looking at the ACL, they’re not going to know what that line was there for, and we’re not going to remove it because it would maybe do some damage.

If you’d put under a mark in there explaining what the Access Control Entry line is for, they would know it’s not required anymore and that they can safely remove it after that. The next thing that we have is the protocol. The different protocols that you can put in here, it’s not just TCP and UDP. Also routing protocols are included as well, like EIGRP and OSPF, they relate to IP, but they’re not actually a TCP or a UDP protocol themselves. They have their own protocol. So if you want to control your EIGRP or OSPF traffic, if it’s going to be allowed to come in and go out, then you can specify that in your ACL.

Other options included in here are ICMP for your ping traffic, also some of our VPN protocols as well, like ESP, you’ll learn about VPNs or virtual private networks in a later lecture when you’re specifying the protocol. Use TCP or UDP if you want that Access Control Entry to apply to traffic for a particular application between a source and a destination. So the example here with Access List 100 deny TCP from the ten 1010 00:24 network going to the 1010 54 network equals 80. So this would be Http traffic between those two networks that we’re going to deny.

So when it’s a particular application, specify TCP or UDP, and then you’ll have the port number at the end so you can see what the application is. One of the options for our protocols was also IP. So we’ve got TCP, we’ve got UDP, and there’s also IP. Use IP if you want the Ace to apply to all traffic between a source and destination address. So not a particular TCP or UDP application, but all IP traffic between these two parts of your network. So an example, there would be access list 100 deny IP from ten dot ten dot 1010 dot o slash 24 going to ten dot ten dot 50 dot 24. So if I go back a slide, you see the first example where we used TCP. It was traffic between those two networks, which was http web traffic. The second example is all traffic.

We don’t care about the application, so we use IP there. The next keyword in our access list command is the source. So you can specify a source address in the format of a decimal notation, or you can say any to specify any source host or host to say a single source host. So those wild cards, it saves you typing out the entire wildcard mask every time. And there’s a couple of examples down below that mean the same thing. So first off, if we wanted to specify an individual host, we could say access list 100. For example, permit TCP 1010 O, it’s a wild card mask. So that equals a subnet mask of 255-252-5255, meaning we’re matching on every single octet. Here we’re looking for a particular host, but rather than having to type out O, we could just say accesslist 100, permit TCP host ten 1010. So it’s easier when you use the wildcard there’s also a wild card for any. So rather than saying Access list 100, permit TCP o dot o dot o dot 0255 dot two five five dot two five five dot two five.

So that wildcard masks is we don’t care about any of the octets will match anything. An easier way is to say access list 100, permit TCP any meaning any IP address. Next up we have the source port number. So in here you can say equals to say match an exact individual source port number, or you can say less than a particular number, greater than a particular number. You can also specify a range in here as well, you can also say NEG, meaning it’s not this particular port number. Specifying the source port number is optional and it defaults to any port. And very often when traffic is coming from a host, it’s going to use an ephemeral port, which is just a random high number port number. It’s the destination port that we’re more likely to be interested in.

For example, port eight for http. Next up, after specifying the source details, we specify the destination details beginning with the IP address, and this is in the same format as the source address. Then finally we have the final options. So in here we can also specify the port number. So we can say equals. For example, equals eight for http traffic. We can also say greater than a particular port number and match everything above that. We can also say less than. There’s also additional options we can enter in here such as TCP flags, such as is the urgent flag set or not. And if we want to do logging or not, when we specify the destination part, the command line has got well known port numbers built in where you can use a name. So for example you could say equals 80 or you could say equals www or you could say equals 23, or you could say equals telnet because 23 is a part for telnet. Both of those will work just fine. So you can say equals eight or equals www. They’re both valid, they both work. So here is an example of a complete access control entry which is access to 100 deny TCP from host 1010 going to subnet 1010 20 o 24, we’ve got the wildcard Masko 25 equals www and the log.

So on those final options you can specify more than one. Here we specified the destination port and we said the log as well to verify your ACLs. After you’ve put the whole configure, the command is Show access list. If you say show access list it will show all of your different ACLs and it is common on production router. So there will be multiple ACLs there because there’s going to be different rules for which traffic you want to allow or deny on one interface than it is on a different interface. So in that case you would have a different ACL for the two different interfaces. So quite often we want to specify the particular access list that we want to look at so we don’t get too much output. So here we’ve said show access list 100 and it tells me it’s extended IP access list 100.

The lines in there are permit TCP host 1010, 30, ten to host 10, 10, 21 equals telnet. So it shows you all of the lines in your ACL. And another really useful thing in the output here is it shows how many matches that you got. This is really useful in troubleshooting. So if you’ve got an ACL to apply to an interface and traffic that should be going through that interface is not being allowed and you’re not sure if it’s the ACL that’s blocking it or there’s maybe some other kind of connectivity issue. If you do this card it will tell you because it tells you if you’re getting matches or not. So if the traffic isn’t working, you do a shoe access list and you keep track of sending traffic through and you can see the counter here incrementing, then yes, it’s being blocked because of the ACL. If a number is not going up, then it must be something else that’s causing the issue. Notice here that we did not specify the log keyword on there. So the log keyword is not required to log those hit counts that you see in the end there. The log keyword is used to log to the console or to an external monitoring server. Okay, so that was it about how to configure our ACLs and how to verify them. But we’ve still got some more information about AC health to learn, so I’ll see you for that in the next.

5. ACL Operations

You’ll learn about access control list operations. And there’s a few things about the way that ACLs work that are not that intuitive. So this is an important lecture to pay attention to because you really need to understand these things so that you understand how ACL’s really work. If you don’t understand them, it’s going lead to really confusing things happening and it’s going to make it really difficult for you to troubleshoot those things as well. So, important lecture. Okay, starting off with how we apply our ACLs. ACLs are applied at the interface level with the access group command. So you saw in the previous lectures about how we build our ACLs, we build them with our access control entries, which are the rules which permit or deny the particular traffic, but that just creates the ACL. You still have to apply it to make it come into effect. And the way you do that is at the interface level with the axis group command. When you are configuring ACLs, don’t forget to apply them with the access group command. It’s actually quite easy to do that.

Okay, ACLs can be applied in the inbound or the outbound direction, and you can have a maximum of one ACL per interface per direction. You can have both an inbound and an outbound ACL on the same interface, but you can’t have two inbound or two outbound ACLs on the same interface. And if you think about it, this actually makes sense because we’ve got our access control lists were made up of entries. If we had two different ACLs with different entries and we applied them to the same interface coming in in the same direction, how would the router know which rule to apply if there was conflicting rules in there? You don’t need to have more than one ACL applied to an interface because you can have multiple rules in the same ACL. If you did have multiple ones, there could be conflicts, router wouldn’t know what to do. So that’s why we always have a maximum of one ACL per interface per direction. Your options are on an interface, you can have no ACL applied, or you could have an inbound ACL only, or you could have an outbound ACL only, or ACLs in both directions.

So let’s talk about this a little bit more as well. And people can get confused about the ACL direction, but there’s a really easy way to not get confused about it, and that is to be like Mr. Mayahagi in the Karate Kid and be the router. So if you’ve got an HCL, let’s say we’ve got a router, and on this arm I’ve got interface fast ethernet zero. And on this arm I’ve got interface fast ethernet fast 10. And you want to control traffic going from a client out this arm, going to a server out this arm. Well, there’s two ways you could apply the ACL. You could apply it inbound on this arm because when you be the router. I know it looks silly, you don’t have to actually physically do it, just do it in your head if you want. But stick your arms out to the side and say this is this interface, this is that interface and I’m interested in controlling traffic going from the hosts over here to the servers over there. But in that case I can apply the ACL inbound as it comes in this interface or I can apply it outbound as it goes out that interface. So whether it’s inbound or outbound, it depends on the direction of the travel. If travel is going from here over to here, I can put it inbound here or I can put it outbound there and it’s only going to affect the traffic which is in one direction.

Okay, so you’ll see what I mean? First time you run into this, anytime you’re thinking should it be in the inbound or the outbound direction or what is this going to do? If you’re confused about the direction, just imagine you’re the router, your arms are, the interfaces stand like that. Think about the direction that travel is going in and then it’s going to be really easy to understand what’s going on. Okay? How to actually configure our access group configuration. So it’s done under the interface here for example, we’ve got interface gigabit ethernet one I can say IP access group 100 out, IP axis group 101 in and then to check which access groups or which access lists are applied to which interfaces. It’s actually easiest just to do a show running config to see this. There’s not a really good show command for this. The specific show command you can use is show IP interface and then the interface number. But when you do that you’re going to get a lot of very verbose output. So if you want to just see the access list information you can pipe it to include access list notice it show IP interface, not show interface.

But again, to be honest, rather than typing in that big long command it’s easier just to do a show run. Scroll down to the interfaces and you can see what ACLs are applied there. If an interface does not have an ACL applied in a particular direction it would say not set. For example, outgoing access list is not set. Next thing super important. The ACL is read by the router from top to bottom. As soon as a rule matches on the packet, the permit or deny action is applied and the ACL is not processed any further for that packet. So this means that the order of rules is important and I’ve got an example that’s going to make it really clear. So our first ACL here, we’ve said access list one deny host 1010 and then the next line is accesslist one permit ten 1010.

So what this will do is it will deny the host ten 1010 but it will permit the rest of the 1010 O 24 subnet. That’s what we wanted to do, we wanted to block just one host but allow everything else in the subnet. Now the second example is going to use exactly the same commands but I’ve flipped the order around. So the second example I’ve said access one permit ten 1010 00:25. So permitting everything from the 1010 24 subnet then access list one, denyhost ten 1010. Well what will happen here is it will permit all from the ten 1010 Osubnet, including 1010 1010 because when a packet comes in from ten 1010 the router will start processing the ACL and ten 1010 is in the ten 1010 O 24 subnet so it will match the first rule and the traffic will be allowed through. It never gets to the second rule which would deny it because it’s read from the top down and as soon as we get a match that action is applied.

So the second access control list example here is wrong. It’s not doing what we wanted to do, we would need to do it the first way. So the order of your access control entries is important. You want to put the most specific entries up at the top of the list, the less specific down nearer the bottom. Another thing is we can inject access control entries into an existing ACL. When you create the ACL, the router will automatically put access control entries on all of your different aces and it numbers them in increments of ten. So when you put the first command in it numbers at ten. When you put in the second one it numbers at 20 and so on. So it puts the numbers in for you. You don’t have to do this. So you can see the example here. We’ve got an ACL access list 110 and we’ve got four entries in there which are numbered 1020, 30 and 40. The reason for this is it allows you to later on inject a rule, whatever you want to into an existing ACL. So for example here before what we had was rule ten was deny TCP host ten 1010 to host 1010 50 ten equals telnet ignore line 15 for now because that’s what we’re going to do in a minute. And then 20 is permit 1010 or 25.

So here we’re denying host ten 1010, we’re permitting everything else into 10 10 00:24 network. Well maybe you’d already configured this ACL and then later you don’t want to just deny ten 1010, you want to deny 1010 1011 as well. Well, if you just added a new line for ten 1011 that would go in below the line which permits everything in the 1010 00:24 subnet and it wouldn’t work. So we need to inject that line higher up than our line 20 permit statement. So the way we do that is here we’re using a named ACL, we’ve got IP access list extended 110 and we say 15, deny TCP host ten, dot 1010, dot ten 1011 to host ten, dot ten, dot 50, dot ten equals telnet that will put it higher up in the ACL. And rule 20. So we’ve got our rules working in the correct order support for injecting Aces into an existing ACL that first came out with named ACLs, but you can do it with numbered ACLs as well now. But the syntax is done the same way that you do it for a named ACL.

Here you can see me doing actually to numbered I said IP access was extended 110, 110 was my numbered ACL. I need to use a syntax like this to allow me to inject commands in, okay? So that’s injecting Aces into an extreme ACL. Next thing super important. Again, there’s an implicit deny any rule at the bottom of all ACLs. So if an ACL is not applied to an interface, all traffic is allowed. You knew that already. If an ACL is applied, all traffic is denied except what is explicitly allowed because of that. Implicit deny any real it’s implicit because you don’t have to type in, it’s always there. So if we created an access list here, we’ve said access list one, permit 1010 below there, there is a deny all command, which is always there. So traffic from 10 10 00:24 will be permitted. Everything else is denied because of the implicit deny all at the bottom of your ACL.

Some organizations, many organizations include an explicit denial at the end of ACLs to log illegal traffic. So they actually type in, like you see here, access list one deny any log. So if you’re wondering, well, why would they put that in when it denies anyway? It’s so that you can log it. So you can send information out to an external server. So if somebody is doing something they’re not meant to be doing, sending traffic that they shouldn’t be, then you’re blocking it. But you’re also going to get a report about that as well. Okay, so with the explicit denial, it means that when an ACL is applied, all traffic is denied except what is explicitly allowed in the access control entries that you configure, if you want to reverse that, so that all traffic is permitted except what is explicitly denied.

The way you do it is you add a permit all statement to the end of the ACL that will then be higher up than the implicit deny any, which is still there. So here we’ve said access list one, deny 1010 00:25, and then access list one, permit any. So we’ll deny what we said in the first line. Everything that we haven’t explicitly denied is going to be permitted. Another thing, and this is one that can confuse you, is that ACLs apply to an interface do not apply to traffic which originates from that router itself. So you see in the example here, we’ve got routers R one and R two and we want to block telnet traffic going from the hosts and the left going to the R Two router and we’ve done that with an access control list on R One. So we said access list 100 deny TCP from any going to any equals 23 and then because we’re doing it on interface R One well we could actually do it in bound on interface fast zero or we could do it outbound on interface fast 10. Hopefully you see what I mean now about the holding your arms out thing and you’ll be able to figure out the direction traffic here is going from left to right. So if we want to control that we could control it either with an inbound ACL on zero or an outbound ACL on 10.

Okay, so we’ve done that and this HL will work. It will stop the host on the left from telnet into R Two. However, if we go onto the command line on R One we will be able to tell net to R Two. You may well wait that shouldn’t work because I’ve done my ACL outbound on interface fast 10 and R One and the traffic is going to go out that interface. The reason it will work is the ACLs do not apply to traffic that comes from the router itself. So if we wanted to block telnet traffic from the PCs and from R One as well don’t do the ACL in R One, do the ACL inbound on R Two. Okay, that is everything about how to configure and understand and verify our HLS. In the next lecture I’ll show you how to do it with a lab demo.