All right, let's start off by just logging into manager
and getting comfortable with how we configure
access control lists.
We're not going to do anything really that complicated.
We just want to configure an access control list
and see the process of getting it deployed
into our environment.
And then we'll go on to the CLI
and make sure that it did take effect.
So what we'll do is we'll create an access control list
that is blocking traffic towards a certain prefix.
So a specific subnet,
and we'll do it maybe against HTTP and HTTPS.
So that would be TCP ports 80 and 443.
And so what we need to do,
if we're going to define anything by a subnet,
usually we want to create a prefix list.
It's not required,
but it does allow us to reuse that prefix list
anytime we want to target that same subnet
with any other access control list.
So in order to perform our ACL configuration,
we're going to come down here to our policies.
Remember, we've got to configure this
as a localized data policy.
So here's all of our centralized policies we've created.
I'm going to flip over to this tab.
And up until now,
we've not created any localized topologies.
And so we'll click add policy.
And right away, we're told to create groups of interest.
What's interesting here is we noticed this list
is actually a lot shorter
than the centralized side of things
when we are creating groups of interest.
And there's just a lot more groups of interest types
that we can create over on that side.
And so on the localized side,
it has its own set of groups of interest,
although it does share a few, for example,
like with VPN list here,
we don't have to recreate a VPN list
just to operate on the localized policy side.
Instead, we can reuse that.
And so there are options there.
So what we can do is we can create a data prefix here.
I'm going to say new data prefix list,
and we'll call this site 11 data.
So we know that we've got a subnet at site 11,
that is 10.10.11.0.24.
And I can create this within a prefix list.
Now I can actually add a lot of prefixes here.
I can add this to the list.
And so there we go.
I could add another one to the list if I wanted to,
but we're just going to create a single one here.
So that should be good for creating a data prefix.
So we can click off and click on
and make sure that it is there.
So now we can click next.
Then we can click next again,
and that gets us to the access control policy.
So from here, what I can do is I can say,
let's add an access control as policy,
and I can add the ACL in here.
So now I'm going to go ahead
and name this access control list.
And again, the purpose here is to block some data.
So we're going to go ahead and call this ACL web block,
because we're blocking our web traffic.
And the description is going to say
that we're blocking web traffic to site 11.
All right.
So now we have the default action for the access control list
and the default action is to drop.
Now, interestingly, we've seen before
that default actions within the route policies,
for example, in T-Log policies was to reject.
So why are we using the word drop versus reject?
That's actually very subtle,
but there's a good reason for it.
It's because this is a data policy.
I'm dropping real traffic.
I'm not rejecting traffic.
I'm actually dropping the packets that are coming in.
Whereas on a control policy,
I'm talking about the spreading of information
and I'm rejecting learning certain pieces of information.
So we could certainly have seen
that Cisco just called them both reject
and that would have been fine.
But I do like the little subtlety there
that we're actually dropping traffic.
And so that should be a good indicator
as far as what's happening on the backend.
So our default action is to drop,
which is true for pretty much every access control list
that we create on Cisco platforms.
Now, if we wanted to change this, there is this edit icon.
And so I could change it from drop to accept,
but we're just gonna leave this as drop.
All right, so next we're ready to add an ACL sequence.
So I can add an ACL sequence here and give it a rule.
So again, Cisco creates this hierarchy
just so I can more easily manage a control list
a little more dynamically in the graphical user interface.
But what we're gonna find is that this feels
like we're creating an ACL at the CLI.
So I just added a sequence rule.
This is essentially like
when I'm creating an access control list saying,
hey, I'm going to now create a line
that says I'm going to allow or deny certain traffic types,
right, from this subnet to that subnet,
equal to TCP 80 or whatever the situation is.
And so that's exactly what we're accomplishing here.
So what am I doing?
Well, remember, we've got these match action statements.
I'm going to match on something
and then I'm going to have actions.
I can match on multiple things as well.
So let's go ahead and start off
by matching a destination data prefix.
And this is where I could enter the prefix manually
if I wanted to, but we created a prefix list for a reason.
So let's go ahead and grab that prefix list
and throw it in there.
We can also match,
I've got to use the scrolling arrow over here,
on a destination port.
So both of these are highlighted now
and every time I highlight one,
it does throw in the parameter for me to define down here.
So I'm going to say port 80.
Now we want to block two different TCP ports.
So you might say, okay, comma 443 or something like that,
but notice that it's a range or separated by space.
So I can only really do a single port at a time.
So I'm going to do port 80 to start with.
And then I have this tab here for actions.
What am I going to do?
Well, we've said that we're going to drop this
and this is where I can tick up a counter
to see how many packets I've dropped
or I can actually log the packet as well.
So I know what type of packet was dropped.
From here, I'm going to scroll down.
Always be careful, by the way,
down here, this is not what we're looking for.
In fact, Cisco will give us an error up here that says,
hey, you've got to save this policy first,
which is really nice because otherwise you might just,
we might find that we cancel out the policy.
We haven't actually saved this yet.
We have to click the smaller save match in actions.
And now we have our first ACL sequence rule,
which is to match this subnet going,
and I can use this down arrow here to see,
going towards destination port 80.
And we are going to drop this.
I know it says enabled.
It's saying that the drop is enabled.
Little confusing there, but drop is the key word.
So we also want to drop port 443.
So I'm going to do the same thing.
I'm going to select match.
Destination data prefix is why a prefix list is nice.
I can just select it again from the list.
I can add a destination port.
This time we'll add 443.
And then the action.
So flip over to this tab.
I'm going to say that we're going to drop this as well.
And then save and save the match and action statement.
So that's well and good,
but now we've dropped two different types of packets.
We don't allow the rest.
And so this is where we do have to be a little bit careful.
I want to click over here now on the default action
and do add that basically allow IP any, any kind of concept.
I'm going to set the default action to accept.
Save match and action.
So I guess we could have done that earlier, but that's fine.
So now we've got it in place.
Everything should be good here.
We can use the arrows to take a peek
and make sure we've got the right port number in,
make sure that we are dropping both of those
and the default action is to accept.
So we've created our access control list.
That's good thing.
Now we have to keep going in order to finish out
creating this data policy.
So I'm going to save the access control list policy.
And so now we've created an access control list
and applied it into this policy.
One thing that we mentioned this earlier
as part of the control policy concept
is that Cisco is creating a hierarchy here
from a UI perspective.
It feels like, okay, we create an access control policy.
We've got to create a data policy.
What's going on?
The data policy is a container
and then I'm adding access control lists
that I have configured into it.
Now Cisco allows us to create an access control list
from here rather than just importing one.
But now that this is created as an access control list,
we'll find that those options at the top there,
the custom options,
allow us to look at our access control lists
and then we can actually delete them there.
We can import them into other policies.
But what we've done is we created an ACL
and now we've injected it into this greater data policy
or localized policy that we're creating.
So I'm going to click next.
And now we could add route policy.
We're not going to do that.
And so now we're giving a name to the localized policy.
So I'm going to call this localized policy
just something like what we're trying to accomplish.
We're blocking web traffic to site 11.
And the policy description could just be
block web traffic to site 11.
Whatever helps us out.
We probably are going to have a standard in our organization
for how we name policies.
So just something to consider there.
So now I'm going to save this policy
and we have created the policy
which contains the ACL within it.
Now, just like I just said,
we've got this custom options.
I can come up here.
I can look at my access control lists.
And remember, this is the ACL name that I created.
So now the ACL itself is listed here,
but the policy I created is here
and it has the ACL configured within it.
So again, we just kind of want to start to understand
the hierarchy of how all this comes together.
So where are we going to apply this policy?
With centralized policies,
we were able to just activate these policies here.
And that's the case because a centralized policy
must be pushed to our SD-WAN controller.
Localized policies, we can't just activate them
because we don't know where we're going to send them.
And these are supposed to go to specific devices.
And so we actually need to leverage none other
than our device template in order to push it.
Now, this is going to happen in two phases.
First of all, we're going to push it to the device
using the device template that'll push the policy
and it'll push the access control list.
The feature template is then going to be required
to be changed in order to add it to an interface.
And that might require us to stretch our minds back
and really think back to when we configured device
and feature templates,
but hopefully that's a good reminder
of how this ends up working.
The device template has feature templates
that will push out interface level configurations,
but the policy itself, the localized policy
gets applied via a device template to a device.
So let's actually start with the device template.
So we're looking at our device template.
We've got our lab edge template here
that's pushed out to sites 11 and 12.
So I'm going to edit this.
And once it loads, we're going to find this link over here
for additional templates.
And down here, it doesn't look like much
nondescript policy just listed here.
This is where a localized policy goes.
So I can select my localized policy block web to site 11,
click update.
So we're going to push this to both of these devices,
both edges 11 and 12.
So I'm going to click next.
And now just like with before, I can click on this.
Let's say this is edge 12 I just clicked on.
And then once it loads, I can click on config diff up here
and it will show me exactly what it's going to do
from a difference perspective.
Let's go all the way down.
And we see that we are, again, under policy.
And then we have a bunch of required configurations.
And then we have our lists,
including the data prefix list that we just configured.
It has that site 11 data prefix.
And then it has the access control list, which is great.
We've got sequence one,
we're matching our destination prefix
and a destination port and we're dropping it.
And then same thing down here,
we're matching the prefix with this destination port 443,
and we're also dropping it.
And then we're accepting everything else.
What you'll notice here
is that it's not being applied anywhere.
All of our interface configurations up here are untouched.
Instead, we're just pushing the policy
along with the access control list.
So let's go ahead and confirm.
We want to push that to our two devices.
And yes, that means we're pushing something to edge 11.
We don't want, we're gonna apply it on edge 12,
but that's perfectly fine.
So we are going to allow this to push and that's a success.
And we already saw at the CLI what it's doing there.
So now we have to worry about how do we apply it?
Well, I already just mentioned it,
but we're gonna go to configuration,
right back to templates here,
go over to our feature template.
And now remember, we've got these interface templates
that define the interface configuration.
So where are we going to apply it?
Well, we don't want to apply it to our transport interfaces.
We wanted to apply it to our gig three interface,
which is facing downstream.
It's facing the host traffic.
So that's where we want to apply it.
So I'm going to edit this.
And this, if we remember,
it always starts me at the bottom for some reason.
So I'm gonna scroll up here to a section for ACL and QoS.
So where do I want this?
I want this inbound on the LAN interface.
This is the LAN interface.
I want it inbound.
So ingress ACL, I'm gonna set this to global and on.
And now this is interesting.
It wants to know what access list to put in here.
Why doesn't it give me a list?
Well, because ultimately it doesn't know
what ACLs have actually been pushed to the device.
Cisco probably could have made that happen
and make it a little more streamlined.
But in the end,
we're really just kind of getting onto an interface
and adding a config.
And so we think about the access group command on iOS XE,
where I specify the name of the access list I want,
and then an inbound or outbound direction.
It's not checking to see if that exists.
And I can technically put any name in there that I want.
So they're replicating that same behavior here.
I have to type it in.
Fortunately, I copied it earlier.
It's that ACL underscore web underscore block
is the ACL name.
And so I'm going to update this, say next.
And if we look at, let's say edge 12 again,
when we look at the config diff,
we'll see exactly what it's going to do.
So, yep, there we go.
So config diff, scroll down just a little bit here.
And we're gonna see that the only thing that we're doing
is adding this access list.
So this name that we just said in an inbound direction.
And so that's being applied to interface gig three.
So that's perfect.
That's exactly what we want.
Configure the devices.
Now notice it's configuring and pushing to both devices.
It's probably not exactly what we want in this case.
So it probably would have been better
to do a device specific configuration rather than global.
But again, this is just a demonstration.
So keep that in mind as you're putting these into your lab
and potentially production environment.
Once this is done, we will go ahead and go over to the CLI
and make sure that everything was configured correctly.
All right, so that didn't take long at all.
Let's take a quick look here.
So here we are on edge 12.
Remember, we wanted to apply an access control list
to edge 12 to block traffic going to site 11.
And so if I do a show SD-WAN run here,
we should see all of the configuration that we put in.
So it starts with that policy configuration,
which will include the access control list.
Let's get down here to where the policies are.
So under our policy section,
again, this is exactly what we saw in the config diff.
We see that we've got this prefix list configured
and then an access control list.
But again, it's not actually applying it to an interface
as part of the policy.
So I've got to scroll up and take a look here
at interface gig three.
There it is.
And we see that the access list has been applied
in an inbound direction.
So that is how we get an access control list
placed onto an interface.
It might feel cumbersome compared to just flat out
doing it at the CLI,
but keep in mind if I do it at the CLI
and I need to do it to a hundred devices,
I'm doing it a hundred times.
Whereas this allows me to do it one time
and applies it to a hundred devices
or however many devices I need it to go towards,
as long as I want it actually going to all of those again.
So that is configuring access control lists,
specifically explicit access control lists
inside of the SD-WAN architecture.