In the previous set of videos where
we looked at IKEv2 and FlexVPN with site-to-site VPNs,
we discovered there's a few more configuration items with IKEv2.
Including proposals, and policies, and profiles.
We also took a look at how those are nested together.
Now with remote access VPN, we have some more stuff going on.
Meaning, we have-- we're going to need digital certificates
for remote access VPNs.
We're going to validate who that server is--
the headend device, the router, with RSA signatures,
with digital certificates. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
with digital certificates.
So we need to make that work.
Also we need to validate who the user is when they come in.
So there's some AAA commands there.
So I'd like to give you a high-level picture of some
of the additional components that we
are going to need to put in the recipe for our FlexVPNs
with remote access.
And then what we'll do after we've
looked at the parts and the new pieces, in the next video,
we'll make a design regarding how
we want to implement-- or follow it up
by actually implementing the solution
and then verifying that design.
So here, let's do this.
For IKEv2, we are going to have everything WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
For IKEv2, we are going to have everything
that we had for site-to-site tunnels,
including the proposals, and the profile, and the policy.
And we're going have to do that again for the remote access
so this user can build a VPN tunnel here.
That also is true for IPSec.
We'll have at least as much as we
did for the site-to-site tunnel, including the IPSec transform
set, and also the IPSec profile.
And with IKE version 2, which we're
going to be leveraging here with FlexVPN,
we can use a lot of the defaults if we want to,
if they meet our needs. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
if they meet our needs.
But if we don't want to use the defaults,
we need to create those individual components.
So let me focus on what we are going
to add in addition to the basics of IKEv2 and IPSec
that we did in our site-to-site video.
We are going to add some AAA methods, including how are we
going to authenticate the user?
So instead of using a nice server with radius,
we'll go ahead and do local authentication right here
on the headend device.
Also because when the user connects,
they're going to need to authenticate this device based
on a digital certificate. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
on a digital certificate.
One of the-- let me bring the big screen for this.
One of the challenges I found is that as people
are trying to lab this up and get their head around this,
if you have to bring in all--
I know I need a CA Server, and you bring in a Windows Server,
and you get that all configured, and then enroll
and everything else, I thought, let me do this.
We do need to have some certificates involved
for the headend device, Cisco iOS running
FlexVPN for remote access VPNs.
So what that we do is let's go ahead
and have the router itself be a CA Server. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and have the router itself be a CA Server.
And then we'll have the router itself say, I trust myself,
and I'll get my own identity certificate for myself.
And that way, we don't have to bring
in a third device in a lab environment,
like a Windows Server or something else just
for a CA Server.
We'll do that locally on the router itself.
So local authentication for the user.
We'll also do a local certificate authority.
And as far as pushing policy down,
if we will say, Hey, only encrypt
and send traffic over the tunnel for the 10 networks,
we're also going to need some authorization policies. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we're also going to need some authorization policies.
Now I know it sounds like when you think of an authorization
policy, whether it's IKEv2 or AAA,
authorization sounds like, Oh, it has permissions.
I'm allowed to do this.
However, the authorization policy
is also instructing, in our case,
the VPN client what to do.
So if we wanted to train this VPN client,
the AnyConnct client that was connecting that it should only
do split telling based on a 10, that
be done through an authorization policy.
Another element we'll need to plan on is addresses.
You might say, Keith, what do you mean addresses?
This guy has an address, the server has an address, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This guy has an address, the server has an address,
but when this VPN is built--
if we want to hand this client a virtual IP address that they
could use for its journey on this network,
we need to identify a range of addresses
we want to use for that.
So let's imagine that we have an address of 10.67.83.51
through 100.
We can assign that as the range of IP
addresses that when the VPN client connects,
it's logically given one of those addresses.
And then when it communicates with internal devices,
it'll look like it's coming from one of these IP addresses WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it'll look like it's coming from one of these IP addresses
from the internal perspective.
And now when the traffic comes back,
the router will now, Oh, yeah.
I know who I gave that address to.
And then it can route the traffic back
over the tunnel over to the PC if that was a response coming
from a server on the inside.
So addresses are another element that we need to plan on.
Another magic trick that this hidden device
is going to pull off is called a virtual template.
And the way this works is that when this client connects
and authenticates, the router is going to say,
Well, I need to keep track of this remote access WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, I need to keep track of this remote access
VPN that's coming in.
And it will take this virtual template,
and it will effectively clone it,
and make itself a new logical interface for that VPN
connection from the VPN client coming into the headend device.
And that's can be based on a virtual template.
So in that virtual template, we're
going to specify an IP address.
And instead of specifying a unique IP address for each one,
we can use a technique called IP unnumbered.
So we get like an interface loopback 1 or 100,
and we give an IP address of 1.1.1.1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and we give an IP address of 1.1.1.1.
And then we get an virtual template mode,
we can say, IP address unnumbered
and specify loopback 1.
So basically this new logical interface
would have the same address as loopback 1 in this case.
All it is, is just a placeholder for this new logical interface
that has been created dynamically
from the virtual template.
So the configuration for remote access VPN
is pretty steep because there's so many moving parts,
but here's what we can do to make it easier.
In the next video, let's put together
a plan regarding what we want to use for the IP addresses WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a plan regarding what we want to use for the IP addresses
and for the pool, and what we want to use
for the split telling policy.
We'll put those details in place,
and then we'll follow it up by doing the configuration
to implement it.
And then we'll verify it together.
So we'll continue that journey, including the design
in the very next video.
And I hope to see you there in just a moment.
Meanwhile, I hope this has been informative for you,
and I'd like to thank you for viewing.