ICND2 200-105

ICND2 200-105

IPv4 ACL issues

Being able to work with extended access lists is critical and it's usually extended access lists that are going to work as traffic filters inside of your organization. Standard access control list, or ACLs are good for controlling sources for network management and to things like our vty lines or they come up when we're filtering routes with the distribute list. But I'm going to think about extended access lists for my filters. And let's go through something that is going to be very familiar to you in your ICND1 journey for troubleshooting extended ACLs.

We look here at this ACL and I want you to make sure you understand, you're reading the whole thing. How many sequences do you see in this ACL and what strikes you about it? We do this command show ip access-lists and you could also have done a show access-lists, would've had the exact same output.

Troubleshooting ACLs

Alright, looking at this access lists here, first and foremost, it has a really interesting name. It's a named access control list called outbound. Doesn't tell us very much except more than likely we're going to be applying it outbound. It's what I could take away from that, we'll see later. Got a sequence number of 10 here and it says, permit Internet Control Message Protocol, or ICMP any/any. So we are going to be permitting ICMP traffic. This is great. We want to allow pings through the router, right. And the first any is for any source, the second any is for any destination. And in this case we don't have like ports, like the eq 23, the eq 25, because right after permit TCP or UDP would've followed for the protocol at the transport layer. And ICMP doesn't need those extra elements, although, you can be very specific, you could say echo or echo reply. So you can get into the specific message types of ICMP and the ACLs to allow for that.

It says here five matches, so it appears to be working right now, we are able to successfully ping from PC1.

But we got a problem now. I do expect for more than just ping. We don't build networks for ping. We build networks and ping is a tool, right? And so maybe, we were getting clients that were saying - hey, I can't telnet or I can't do anything past that router. We would want to be able to troubleshoot and amend our ACL to solve the issue. So, let's go ahead and verify where this access control list has been applied.

Well we can see here that if we use show ip interface GigabitEthernet 0/1 and we're piping just to include access list. This access list called Outbound has been applied outgoing on Gigabit Ethernet 0/1 on our Branch router.

Branch#show ip interface GigabitEthernet 0/1 | include access list
 Outgoing access list is Outbound
 Inbound access list is not set

How confusing is that. Their naming is pretty messed up, right. So I want you to see this and go. I'm not going to do that, I'm going to name my ACL something that makes sense. Now at laboratories, we might just have the name of filter but even filter is better than saying outbound because you could still apply the outbound ACL in the inbound direction and then how confusing would it be. You would be baffled. I mean it's even hard to read it here. But directionality does come into play and when you're thinking about directionality, it's from the perspective of the router. It's looked at as it goes through that interface in the direction in which it is applied. So if the traffic is really leaving this interface and the directionality of the ACLs outbound, then it will be scrutinized.

But if it's reversed, the traffic is going one way and the ACL directionality of which you've applied it to is the other way. And it's going to go right past your logic and that is a classic mistake. Directionality is important, so when in doubt think in the direction from the perspective of the router, okay. Is it coming in, is it leaving.

Let's look at this problem that's been presented to us. PC cannot telnet. Just to recall, were we able to successfully ping? We were and how confusing is that. But we are not able to telnet. Let's remember the access control list we created. There was one entry in it and it said permit ICMP. What happens to all the other traffic that is not ICMP related? It's denied because there's the black hole effect going on. And we're not talking about someone creating small black holes, we're talking about the black hole that sits at the end of an extended ACL. It's called the implicit deny all or implicit deny any. It's going to suck down all of our traffic. So our ACL at this point is really confusing in the sense that it's only permitting ICMP which we would never do in the real world because hey, what's the point of only allowing ICMP? There's none.

Alright, so what's the point of only allowing ICMP and telnet then? Not much. We're probably, in fact, more likely to deny telnet and allow for most other traffic because telnet is a security vulnerability, because it is a plain text, clear text, unencrypted management protocol. So keeping this example we want to add the ability to telnet that from PC1 to the server. So how would we do that? We'd have go back and modify our access control list.

We get to revisit named extended access list configuration, which is awesome and we should also be mindful of the sequence numbers.

If you recall, there is a sequence number of 10 on our ICMP permit statement and I would be thinking about that right now. But at any case, if I go into global config, if I want to modify the named access list, you can do this for numbered also, you can follow this syntax. So even if your ACL was ACL 100, which is numbered, right, you could say IP access-list extended 100 and you would be granted this enhanced editing capability and then you adjust as needed. Now when you do this command, you have to think where does it go. We did not specify the sequence number which means the router is going to look at the very last sequence, it's going to add 10 to that and that's going to be the sequence that you get here. So this would be sequence number 20. Is that good or bad? It's up to you. If you wanted this to be earlier in the logic, you could've specified it with a 5. Why not just put telnet after the permit statement and why beat, why beat around the bush here? Why not just say permit telnet? Well, we have to specify the protocol first.

Branch(config)#ip access-list extended Outbound
Branch(config-ext-nacl)#permit tcp any any eq 23

Telnet is a protocol. We have to specify the transport layer protocol. In this case, telnet uses TCP. So we specify the transport layer protocol, source, destination and then what specific service protocol are we using in this case? It's telnet, so equal to 23. But we could also type telnet and it would be accepted as well. So we're allowing from any source to any destination for the destination port of 23, which is usually where you want to specify the ports because that's the initiating pattern. The destination port for initiating traffic is what you can predict. Source port is ephemeral, it's generated randomly. You're not going to know that so you're going to put it at the very end. And if you find your port operator sitting in between source and destination, it's a big warning sign that, that ACL entry is not accomplishing what you wanted.