- [Instructor] When we're configuring access control lists,
one way you can get more flexibility with what you're trying
to achieve is by using an extended ACL.
Extended ACLs have some features not found in standard ACLs,
including the ability to match both source
and destination IP addresses.
Remember that with standard ACLs, they're only able
to match source IP addressing.
Also, rather than affecting the entire protocol suite
as standard ACLs do extended ACLs can permit
or deny specific protocols within the IP suite.
So you can very specifically filter things like HTTP
or telnet traffic rather than blocking all IP traffic.
The number ranges used by extended ACLs are 100
through 199 for the normal range,
and an available expanded range of 2000 through 2699.
Just as we mentioned with standard ACLs,
extended ACLs can also be named
which we'll examine in a future video.
As for best practice placement of an extended ACL,
these should be placed as close to the source as possible.
This is the exact opposite of the recommendation we examined
with standard ACLs, where we pointed out
that standard ACLs should be placed as close as possible
to the destination having more flexibility
with filtering source and destination addressing allows
for this with extended ACLs.
The thought is that if we're able to look
at the destination IP where a packet is bound for,
there's no use letting the packet travel
throughout the entire network and take up our bandwidth
if it's eventually going to be dropped anyway,
so we want to place these as close as possible
to the source of our traffic.
Here we have the same topology as we use
with a standard ACL configuration.
But this time we want to look specifically
at blocking a subset of the IP suite.
We want to make sure that PC one does not have the ability
to telnet to the server.
All other traffic from PC one such
as ICMP pings should be allowed to reach the server.
As for PC two, we want to allow all the traffic from there,
including telnet traffic.
So let's connect to a live interface and take a look
at that configuration.
Before we get started with our configuration,
I do want to reiterate the fact from an earlier video
that ACLs are processed sequentially from the top down.
So the first ACE the first Access Control Entry,
and the ACL that matches our traffic is going
to be processed, and then ACL processing is stopped.
This is particularly important here
because order matters very much.
One of our goals is to allow all IP traffic from
the 10.1.1.0/24 network.
If we placed that as our very first ACE
when we configured our ACL, then we're going to have problems
when traffic arrives from that network,
the very top ACE would be matched
which would be a permit command, and then the deny command
that is further down in the ACL would never get processed.
So very important here,
we want to place the deny process at the top.
And in general, anytime we do have more specific filtering,
taking place with an ACL, we always want to place
to avoid situations like that.
So let's go over to our router,
and we'll go under global configuration mode.
And we'll say, access-list.
We'll follow that with a number
in the extended number range.
Again, if we use contextual help, you can see all
of those again here.
I always start at the beginning of those ranges.
So the very first one available is number 100.
So I'll just choose that number.
And the first thing we want to do is use the keyword deny.
And if we look at contextual help again,
you can see all of the options we have at our disposal.
Now, we certainly could choose IP as that option,
and that will block all IP traffic.
But in our case, we want to be more specific
because we have the option to do that
with this extended ACL.
And remember, the goal was
to specifically block telnet traffic,
we want to block telnet traffic from PC one.
Telnet uses TCP port 23 four communication.
So this TCP option is exactly what we want to look at.
So I'll say TCP, and we actually won't put the port in there
just yet that actually comes at the end of the command.
So we'll stop with TCP for the time being.
And the next thing we want to use,
if we look under those options is the host keyword.
And that's going to identify the source
and destination for our traffic.
We'll identify both of those hosts
with the source being first so I'll say host
and we want to deny traffic coming from PC one,
which is the host at 10.1.1.5.
Next we again want to say host
So that we can identify the destination address,
which is our server at 192.168.3.50.
And now we're ready to identify the port number.
So we can say eq, which stands for equals.
And if we look at our contextual help again,
notice that you could actually call out a protocol here.
So we could actually say telnet.
If we wanted to do that we could put in telnet.
Or if we know the actual port number,
we can just put the port number in, which is actually
what I'm going to do, I'm going to say 23.
So if you know the port number, it's a really easy shortcut
to do it that way.
So I'll hit enter, and that is our first ACE completed.
So now we want to place since we have a deny command,
we want to enter our permit ACE into the ACL because remember,
we want to permit all the other traffic from the PCs.
Again, we're placing those more specific ACEs at the top,
and the more general ACEs at the bottom.
So the command we want again, access-list,
we again want to say 100,
so that it's placed in the same ACL.
This time, we want to say, permit.
And we want to allow all IP traffic from the hosts.
So we can say, IP, we can use that general protocol here.
And now we could use the any keyword if we wanted
to, we could actually say any any
and that would allow it from any host to any destination.
And that's certainly valid.
But I want to show you how to do that.
More specifically using the wildcard mask.
So instead of saying any, let's say 10.1.1.0
and then we need to follow that with a wildcard mask.
So not a subnet, remember, we want to do a wildcard mask.
And we can calculate the wildcard mask by simply subtracting
the subnet mask from the value 255.255.255.255.
So in our case, our subnet mask is /24 or 255.255.255.0.
So if we do subtract that,
we get a wildcard mask of 0.0.0.255.
So that's how that is calculated.
Now for our destination, I will go ahead and say any instead
of putting in the server's IP address,
because in a real world, this server may actually be out
on the public internet.
So if you did put a specific IP address here,
you would only be permitting that IP traffic to that server,
and it would still be blocked to all
of the other destinations on the internet.
So we'll act as if this is on the public internet,
and we'll put any that's going to allow that traffic out
to any destination, not just to the server.
So we can actually hit enter now.
And that completes our ACL configuration.
So now what we want to do is we want to apply
that ACL to an interface.
So we'll go under interface gig, 0/1.
And we'll say IP access-group,
the number of days ACL which is 100.
And since that is our inbound interface,
we want to use the keyword in, to apply
that in the inbound direction.
And then we can hit enter.
Now if we exit, and we say show access-list.
Now we can see our extended numbered ACL,
which is number 100.
And we see both of our ACEs listed here
we see the top deny ACE with a sequence number of 10,
the bottom with a sequence number of 20.
So that all looks good.
Let's test this out now.
Let's go over to PC one.
And let's try to ping the server
by saying ping 192.168.3.50.
That is successful and that's what we would expect to see.
Let's try to connect via HTTPS we can do that
with a telnet command followed
by the IP address of the server.
And we can call out a specific port.
So let's try that over port 443.
You can see that's open.
So that works as well, it is letting us attempt
to connect via that method.
Now let's try our normal telnet process.
At this point, we've been able
to use a couple of different methods to reach that server.
So let's try our typical telnet
over the default port number.
And look at that destination unreachable gateway
or host down.
That's exactly what we would expect
to see here if things were configured correctly,
so that's great.
So let's jump over to PC two make sure
that's working properly.
So first, we'll ping, the ping is successful.
Let's try to reach that over HTTPS over port 443,
that also works for us.
And finally, let's try our normal telnet process
which should work for us from PC two,
and indeed it does, we get prompted for access verification.
And if I put in the password that works correctly,
you can see that we are at the server command line prompt,
exactly as we would expect to see,
which was exactly our goal.
So that's a look at
how we can configure an extended numbered ACL.