All right, so on to the onboarding process.
We know that we've got a challenge here because we have a new router that we
want to bring
online with our SD-WAN environment.
The challenge with this is twofold.
First of all, we want to make sure that we gain proper access.
Proper access, meaning that we're connecting to the correct network and that we
're not
onboarding devices that don't belong to us, that's going to be important.
But we also need to resolve some of these chicken and egg problems, so we'll
just call this
the discovery process.
And one of the reasons why this is a challenge is because as much as possible,
I want this
to be an automated process.
One of the challenges of traditional WANs is the fact that this new site could
be three
countries away, or half a world away, or wherever this device is, it could be
prohibitively
restrictive for me to actually go and be the one to install it.
And so the person over here installing this device could just be a manager, or
it could
be just a front office or back office worker, something like that.
It could be anybody who isn't considered technical.
And rather than sending somebody on site who is technical or trying to do some
sort of
screen share, either way, we would really rather the manager just be able to
plug it
in and have it find everything that it needs to find.
It needs to find a lot.
It needs to find especially the controllers that we just talked about, and
those need
to form a connection with one another.
And so this can be a big challenge, but it goes beyond the controllers.
For example, what happens if this is the internet, and I'm running NAT, as many
internet
connections do, and I need to form an IPsec tunnel with another router that is
also running
NAT.
Remember, that's the goal here is to form an IPsec tunnel.
But forming an IPsec tunnel from one NAT device to the other, NAT device is
going to require
external coordination.
We have to do what's known as a NAT punch through or firewall punch through in
order
to make this happen, where we both send traffic at the exact same time, and
therefore the NAT
thinks that the other side's initiation of traffic is actually return traffic,
kind of
an interesting way to bypass the problem of how do I get into NAT, where NAT
normally
blocks coming from both directions.
So the NAT punch through concept is great, except again, it does require
external coordination.
So all that to say, we are ready to now talk about the SD-WAN validator,
formerly known
as the V-bond.
And again, we see already why we used to call it the V-bond, because it was
bonding a device,
not only into our environment, but to other devices.
It really was the glue that kept everything together.
So now we've called it a validator, because even though the V-bond kind of
refers to this
discovery and process, the validator part is tied into this concept of proper
access,
where we're validating the fact that this router even belongs on our network.
Now what's curious about the validator is that this is actually just going to
be an
edge device running the same software that edge devices run.
In other words, this isn't a virtual machine that's running Linux or Ubuntu,
whatever,
the flavor of Linux that we want to deploy.
This is actually an edge device that is configured to run as the validator.
So that means a couple of things.
First of all, this could be a hardware component.
We could deploy an actual physical edge device onto our network.
It could sit over here, and it could be tied into our running and switching
environment
or whatever the situation is.
However, oftentimes we still run this as a virtual device, because we can
deploy our
edges virtually as we talked about.
And so oftentimes we're still going to deploy this as a virtual device, even
though it isn't
a virtual machine that I would just deploy into my environment.
Now the validator, like the V-Smart or the controller, is going to form secure
tunnels
with the edge devices.
The edge device comes online.
It's going to form this connection, and this is going to be a DTLS connection,
meaning
that it's UDP based.
Now this already begs a question about the chicken and egg concept we keep
mentioning,
which is how does it know where the validator is?
Well, there's actually a couple of ways we can do this.
First of all, we could just do it as a manual configuration.
I could log into this device and tell it where the validator is.
However, again, we want this as automated as possible.
So ideally, we're not going to have to do this every time.
Instead, usually we're going to try to take advantage of Cisco's plug-and-play
portal.
This is part of our smart licensing configuration, and Cisco is made available,
and plug-and-play,
generally speaking, even outside of the world of SD-WAN is all about the
automated deployment
of new devices, where they plug and play it, and you plug it into the network,
and it
plays.
It downloads the configuration, and we are able to configure that via the plug-
and-play
portal.
So that would allow the edge device to know where our specific validator is on
the network.
So then it can reach out, form the DTLS tunnel, and now we can start to
discover the SD-WAN
environment that we're trying to join.
Now the first step here, proper access, this is going to lead to the validation
process,
which is based on authentication.
Authentication is a major part of our SD-WAN deployment.
Security was baked in from the ground up.
It was not an afterthought when it comes to the solution.
We are going to perform authentication via a couple of different mechanisms.
First of all, we're going to have a whitelist model as it's known, meaning that
I'm going
to have to use explicit configuration, or really allowing things explicitly, if
I want
a device to join.
So where do I create this?
Well, I actually create this in the manager.
So I, as the admin, going to log into the manager, which we'll talk about in
the next
video, and I create the whitelist, meaning a list of all of the routers, the
edge platforms
that are allowed in my SD-WAN domain.
So that's the first step.
I need to make sure that this router is even allowed into the SD-WAN
environment.
We also are going to check certificates.
Certificates are a major part of the SD-WAN environment as well.
It makes sure that we have actual authentic devices, meaning that this isn't
some hacker's
attempt to create an SD-WAN router that can join our SD-WAN environment.
We need to show that it's authentic, and it needs to be a mutual authentication
process,
because it's not just about making sure that the device is not a rogue device.
We do need to make sure that it is authentic, but the router needs to make sure
that the
SD-WAN environment, that this is not some fake environment that was created to
try to
fool this SD-WAN device, which maybe got logged off of an existing environment,
is coming
back online, and the threat actor has created a virtual environment in an
attempt to get
network traffic.
We can say that that doesn't seem likely, but at the same time, it's absolutely
possible,
especially if a threat actor is really determined to crack into a particular
organization.
So this needs to be a mutual authentication process.
There we go, mutual authentication process to make sure that not only the
device is authentic,
but also that the SD-WAN environment is the environment I think I'm supposed to
be connecting
to.
Now, here's what's interesting.
At the end of this process, the DTLS tunnel is actually torn down.
This is the one management device between the controllers and the managers,
where we
don't maintain tunnels over the course of time.
These DTLS tunnels that we form between our edge devices and our validators,
they are
not permanent.
This is a temporary connection because I only need it until I'm onboarded onto
the network.
Once I'm onboarded and I know where my controllers are, at that point I can
receive information
that tells me where all of the edge devices are.
So that is the process by which we join the network.
So that's all well and good, except there's one other major caveat to all of
this.
And that is that our validators must have a public IP address.
So the validator, unlike all the other devices which can have private addresses
, must have
a public IP.
Now there's a couple of ways to do this.
First of all, I could just have it in a cloud environment or possibly in a DMZ,
where it
actually has just a single public IP address that it's configured to use.
Or I can use one-to-one static NAT.
This part is important because it's, yeah, the validator is on my private
network, it
has a private IP address, but because it's using one-to-one static NAT, it
effectively
still has a dedicated public IP address.
Why is this so important?
Well for two reasons, one, because of the discovery process, again, we're not
part of
the network until we can join the network and we can't join the network until
we have
connected via the validator.
So the discovery process is very important that it has a public IP address.
That said, even in a world where maybe we don't feel like we need that, we're
not connecting
through the internet, we're connecting through MPLS, we're going to have some
routes this
and that we could argue that, well, maybe we don't need it in every case,
however, the
other situation we need it in is NAT traversal.
And we just briefly touched on that up here, but the idea is that if we have
two devices
behind NAT, then we have to have a device that coordinates the NAT traversal.
And that is the job of the validator to make sure that we're coordinating that.
We know exactly which public IP address we're targeting and we can trigger that
at the appropriate
times based on this external third party between, you know, that's going to
facilitate it.
So that is going to require a public IP address.
It's the only device that requires a dedicated public IP address, but we do
need to make
sure that that's a part of our configuration when we first configure the valid
ator.