Access Control Lists, or ACLs.
These are a huge part of our traditional network security architecture.
And the idea here is to create traffic filtering.
We want to make sure that we're not allowing traffic between hosts and networks,
or between networks and networks, that we don't want to allow.
And as we might imagine, this is going to be very important for us inside of the SD-WAN architecture as well.
is that when we look at an edge device,
we already have an Access Control List configured right from the get-go.
And we might not realize it.
We have a transport connection to our biz internet color here.
We form tunnels across it.
And we may remember at the start that we said that this interface is what we refer to as being hardened.
Meaning that it is pretty well locked down from a security perspective.
This is very, very important in the SD-WAN world,
because we might be connecting to an internet circuit somewhere in the world,
and we can't actually configure it before it connects to the internet and downloads its config.
So it needs to be hardened out the gate.
And so what we find is, yes, it's going to allow us to form a tunnel.
And once we form the tunnel, we'll allow everything through that tunnel.
But we never want to allow everything through this interface.
So we can get an IP address, and we can perform DNS resolution.
But then also HTTPS, which is important from a programmability perspective.
And, of course, ICMP, which allows us to at least see if our device is online.
That's very important from a troubleshooting perspective.
But these four are the only services that are allowed.
And we may recall that when we look at it from a CLI perspective,
we use this very important command, which is known as allow service.
So when we take a look at this, what we find is that we are filtering all of this traffic
using what's known as an implicit ACL.
This word implicit is interesting.
If we're not super familiar with the word, or maybe English isn't our first language,
implicit has the same root word here as imply, which is basically meaning it's inside.
And sometimes when we say implicit, it also can mean invisible.
Meaning that we can't see it. It's not actually there.
Well, this command is there, allow service, but we don't actually see this access control list.
But just because we don't see it, it's actually still there.
It is implied. It's an implicit access control list.
And this implicit access control list is responsible for hardening this transport interface.
So that's great and all that we have an implicit access control list on our transport interface.
But at the same time, it's important for us to recognize that we've also got interfaces
downstream of these edges that are on the service side.
This is where our VPNs exist.
So for example, I might have hosts over here on this service VPN,
and then we've got another edge over here. This is a whole other site.
And these hosts now are downstream of it.
And maybe this is all part of the same VPN.
Call this VPN 25, VPN 25, two different subnets within the same VPN.
So what if I want to make sure that these subnets cannot communicate to one another?
How would I accomplish this?
Well, at this point, this is going to require an actual configuration of an ACL.
This communication can be blocked by doing what we normally do with configuring access control lists.
And so we're going to configure this in a way that really feels a whole lot like it is on iOS XE.
Now, again, we look at the explicit word, we're talking about it being more of an outside, more visible.
It's something that we are intentionally configuring.
And we're going to be able to see that it's there.
So what I can do then is do my traditional filtering to say, hey, I'm going to deny certain traffic types.
So maybe I'm denying from one subnet. We'll call it subnet A over here.
And I don't want it to be able to communicate to subnet B on the right.
And then I can apply it here or I can apply it here or apply it here.
And I have to specify the direction as well.
So is this filtering in an inbound direction or is it filtering on an outbound connection?
We can filter on all kinds of things. We can filter on subnets, on ports, on protocol numbers, ICMP, this and that.
We'll take a look at the configuration coming up here real soon.
So that's great and all, but we know that in the world of SD-WAN, that we don't usually just get on and start configuring things.
We're in the middle of talking about the policy framework and the architecture that SD-WAN builds around it.
And so our explicit ACLs, if we're going to configure those, must fit into this policy in some fashion.
And so we've talked about a lot of different policies.
For example, we've got centralized versus localized. We've got control versus data.
And so pause the video for a moment if you want to and just try to think through, OK, which type of policy does an access control list fall into?
Is it centralized or local and is it in control or is it data?
And so if you've had a moment to think through that, the answer, we can probably deduce this, but just to be clear, it is localized.
This is not a centralized concept. I'm not controlling control plane information.
I'm sending it out from a centralized controller.
This is something that has to go on an actual interface.
So that's why it's localized. Interface policies are always going to be localized.
And again, we're not filtering control plane information.
Instead, I have real traffic coming into one of these access control lists and it's dropping real actual traffic.
I'm not dropping information. I'm dropping real packets.
And so because of that, it is going to be a data policy.
A localized data policy is exactly what our explicit ACLs are going to be a part of.
Now, just because it's localized doesn't mean I have to get onto this edge via CLI and do the configuration.
I certainly can if it's not in managed mode, but I can still get into here me as the admin.
I get into my manager configuration, and then the manager is actually able to push this out.
So, yeah, it's sort of centralized, I suppose, because I'm configuring my access control list here in manager.
And I can go and I apply, I can apply the same access control list to three different edges and three different interfaces.
But again, we're not talking about centralized versus localized, meaning that where we configure it.
It's really more about how it's enforced and it's enforced locally.
And again, because it's actual data plane traffic coming in, that's why it's a localized data policy.
Now, one last thing to address, and this is going to be something that we look at later in detail coming up.
But the idea here is what happens if I have an explicit ACL on top of an implicit ACL?
Is this even allowed?
What we're talking about here is recognizing that this implicit ACL already exists on an interface.
And so could I configure an access control list?
If I configure it, that means it's explicit and put it on a transport interface that already has a implicit access control list sitting there.
And the answer is yes.
We can answer that question very, very seamlessly.
So we can actually do explicit.
I'll get rid of the question mark here.
We can do explicit and implicit at the same time.
But now that creates another set of questions, which is how do these two interact with one another and which one ultimately takes priority?
And they actually kind of link together in a rather unique way.
Specifically, we are going to favor the explicit rules first.
Meaning that if the explicit denies something that the implicit allows or the explicit allows something that is otherwise denied by the implicit, any of those conflicts, the explicit is going to win out.
So if the explicit rules don't account for anything, then we look at the implicit or something specific.
Then we're going to look at the implicit rules next.
So this is a one and a two.
But notice number three here.
The third thing we're going to evaluate is looking back at the explicit access control list and specifically the default action.
This is what I mean by one doesn't just flat out win the whole thing.
Because if that was the case, then whatever the default action for explicit would pretty much override whatever happens here at implicit.
Instead, we're going to look at the sets of rules first, favoring explicit over implicit, and then we'll take a look at the default action there at the end.
So as a quick example, if I wanted to create an implicit rule that actually, let's say, denies, I want to deny HTTPS.
So I create that and I apply it.
Well, its rule gets taken a look at first.
And so that actually is going to deny HTTPS from coming in on that interface, even though my allowed service command, the implicit ACL, otherwise allows it.
Furthermore, if I wanted to allow, let's say, BGP to come in on this link, then I could do so with an explicit ACL.
And yeah, it's denied by the implicit, but it doesn't matter because the explicit is largely winning out.
But if it is a deny all at the end, that's the default action, then even though I'm denying everything else that I don't allow, I'm allowing BGP, but I'm denying everything else,
the implicit still allows these three to go through because that gets evaluated before the default action there at the end.
So again, we'll see this in action coming up.
We're going to do a lab on it just to make sure that we really understand it.
But for now, go ahead and jot that down in your notes and understand that in the end here, we do still have the capability of deploying access control lists into our SD-WAN environment.
If we configure access control lists ourselves, they are known as explicit ACLs, whereas now this allow service command that we've seen both in the manager and the CLI,
that command is allowing us to configure and control traffic on our transport interfaces.
That's known as an implicit ACL, and there is a set of rules that define how they interact when we have both of them on the same interface.