So now it's time to begin the IPsec configuration here on site 4.
So let's head over to site 4 and let's begin.
So one of the most important things we need to do right here
is to make sure we're on the right site.
So I'm going to go ahead and head over to site 4.
So this is the NSX manager for site 4.
I have it in dark mode here to help remind me
that this is site 4 and not site 3.
And so here in site 4 under networking and VPN,
we have absolutely no VPN services enabled
for our tier 0 gateway.
And we have no IPsec sessions, et cetera. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we have no IPsec sessions, et cetera.
So let's begin by creating a VPN service
and enabling it on our tier 0 gateway.
So if we at the moment went to network topology
and then we went to our tier 0 gateway right here
and hovered over services,
it's going to indicate that we have gateway firewall rules
and DHCP and that, but we don't have any VPN services yet.
So we're going to fix that by going back to VPN.
And then in the main window here with VPN services selected,
we'll click on add service.
And from the dropdown, we'll click right here on IPsec
to add an IPsec service. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to add an IPsec service.
And let's call this site 4 IPsec.
And the service type is IPsec.
And we want to associate this IPsec service
with our T0 gateway.
And that's this one right here.
So I'll choose that from the dropdown
and we'll take all the other defaults and click on save.
And I'll click on no.
So now that it exists,
if we went back to our network topology
and if we went back to our tier 0 gateway here
and hovered over services,
now we have the VPN service available as well.
And then what we can do is leverage that VPN service
and create a specific IPsec route based VPN session WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and create a specific IPsec route based VPN session
from site 4 over to site 3.
So to do that once again, we'll go back to VPN.
And then with VPN selected,
I'm going to go ahead and collapse the left hand side
to give us a little bit more room here to work.
And then we'll click on the sub tab here for IPsec sessions.
And then we'll click on add,
we'll add a route based VPN session
and put in the details for site 4.
So we'll click on add IPsec session.
We want to do route based,
which is going to build the logical network,
the 1034, 34 network that we're using WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the 1034, 34 network that we're using
between site 4 and site 3.
So we'll click here on route based from the drop down
and we'll call this one to site 3.
So we're on site 4.
So this session called to site 3,
we very easy to remember what this specific IPsec session
is going to, it's going over to site 3.
It's going to be route based based on the choice
we made from the drop down.
And then for the VPN service,
we're going to choose the VPN service
that we just enabled a moment ago.
And then for the local endpoint from the drop down,
we don't have any local endpoints yet created,
but we can do that right now. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
but we can do that right now.
So the local endpoint here on site 4
is going to be 24.1.2.40.
It's the reachable IP address that we're using
in this lab topology.
So we'll click on the three dots.
We'll create a brand new local endpoint for site 4
and we'll put in the name,
I'm going to call it 24.1.2.40.
And for the actual IP address,
it's going to be 24.1.2.40.
And then for the local ID,
again, we don't have to put it there
because it was just used the actual IP address by default, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
because it was just used the actual IP address by default,
but I'm going to hard code it just for grins
at 24.1.2.40.
And that looks great.
So we'll go ahead and click on save.
So now we have the name of this IP succession.
It's route based.
We're using this parent IPsec service
and the local endpoint is 24.1.2.40.
That's both the name and also the IP address
inside of that endpoint.
And then for the remote IP,
that's the peers address, which is 23.1.2.30.
And that's the reachable address over at site 3.
So as we continue our configuration, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So as we continue our configuration,
let's go down to the authentication mode.
If we're using pre-shared keys over at site 3,
we want to use pre-shared keys over here at site 4 as well
for the session going back and forth between them.
And then I'll go ahead and put in the pre-shared key
that I put in over at site 3.
So I've just supplied that pre-shared key
and just to confirm it's the same key
I used over at site 3.
Fantastic.
And over here on the right, it wants the tunnel interface
address.
And again, the tunnel here is referring
to the logical subnet that we're using between site 4
and site 3. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and site 3.
So here at site 4, we want to use 103434
with the last octet of 44 based on our plan.
And that is a slash 24.
Now, there's only two people on this network.
It's going to be site 3 and site 4.
So we don't really need to use a slash 24.
But since it's all RFC 1918 private address space anyway,
we can go ahead and not worry about wasting a few IP addresses.
And then here for remote ID, we could also leave that blank.
It'll just go ahead and use the remote IP address
as a remote ID.
But if we want to hard-code it here as well, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But if we want to hard-code it here as well,
we go ahead and put that in as 23.1.2.30.
And as we go through the configuration,
any typos or mistakes that we've made
will become apparent if the IP sector tunnel isn't working.
So we'll cross that bridge when we come to it.
So let's just take a look at the details here.
I think I have everything correct.
And we'll click on safe.
All right, so now here comes the moment of truth.
Currently says uninitialized.
We'll click on refresh.
We're hoping for some green indicators right here
to indicate that that tunnel is working.
And it is.
All right. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
All right.
Do I sound surprised a little bit?
Because just one typo with, for example, the IP addressing
or the peer and so forth, that could cause it to fail.
But that looks good.
So if we click on view statistics here,
that's going to show us statistics
for the actual IPsec tunnel for the traffic going through it.
And I would expect this to be all zeros.
Because at the moment, we aren't sending any traffic
through that tunnel.
So if we were to bring up some clients,
in fact, we've got a couple of clients up and running.
I've got the little VM red here and the little VM violet
over here.
If we were to bring them up and try to ping each other, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If we were to bring them up and try to ping each other,
that's not yet going to work.
So let me go ahead and walk you through that.
And then let's talk about why the IPsec tunnel,
although it's in place, really isn't too valuable yet.
So here is the little VM site three red,
which is representing this icon right here
for the little red VM.
And let me bring in the little VM representing
this VM right here.
So here is the site for violet VM on the right.
And here is the little site three red VM here on the left. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And here is the little site three red VM here on the left.
So even though we verified that they can both reach
the internet, we did that in a previous step.
Now, if we try to ping, for example, over to 10.44.0.
And then we confirm the IP addresses here real quick
with an IF config for ethernet zero.
And I'll do it on both sides.
I have config for ethernet zero.
So from the left hand side from the red VM,
we'll do a ping over to the violet VM's IP address
of 10.44.0.151 and press enter. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of 10.44.0.151 and press enter.
The results there aren't too exciting
because they're not working.
And on the right hand side, on the violet VM,
if we did a ping over to 10.33.0.152 and press enter,
that also is going to be too exciting
because it's not working.
So let me move those two VMs off to the side for a moment
and let's talk for a moment why that's not yet working.
And here's the reason.
Even though this logical network is up 10.34.34.0.
And also we could verify this tunnel is up and active WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And also we could verify this tunnel is up and active
by going to either of these edge devices,
though the active device for the T zero gateway.
And we should be able to ping across that
to the other side's address.
So at site three, let's go to the edge node
that's active for the T zero gateway.
And let's do a quick ping over to 10.34.34.44
just to verify that it works.
So here's the NSX manager for site three.
Let's go to our topology.
Let's go ahead and double click on the T zero gateway.
And just to confirm which device is active,
it is edge lab three dash one, which is the active edge node. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it is edge lab three dash one, which is the active edge node.
And if we click on that edge node,
it'll confirm for us the IP address,
the management IP address of dot 36.
So let's go talk to edge one here for a moment.
So here is edge one.
So now we're connected through an SSH session
over to edge one.
And let's type in get gateways, press enter.
And let's go into VRF one, which is the VRF
for our services router.
So we'll type in VRF one.
And from here, let's do a get route, press enter.
And this confirms for us that we are directly connected.
So that's T zero C for T zero directly connected network WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So that's T zero C for T zero directly connected network
103434.34.
So we should be able to ping from this VRF 1034.34.44,
which is the other end over at site four.
So we press enter, that works, no problem.
However, the problem is if we do a get forwarding,
this helps answer the question,
what would this services router do
if it ever got a packet that needed to be sent
over to the 1044 address space?
The answer is that 1044 is not explicitly
in the routing tables.
So the default route would be used.
And then it'd be up to our service provider WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then it'd be up to our service provider
to go ahead and probably drop that traffic
because it's trying to be sent to a private RFC 1918
address space.
So what we need to do is train both tier zero gateways
that if they ever get traffic to the subnets
at the other site, instead of sending it out
to their service provider, what we need to do
is train the routers to go ahead and use the next top address
of dot 44 from the perspective of site three
on this 103434 network.
And from site four's perspective,
for traffic that's trying to go over here to 1033,
we need to route it this way using this next top address.
So the moment traffic between here and here WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So the moment traffic between here and here
is not going over that logical network.
Instead, from a routing perspective,
it's trying to go out to our service providers.
So if we want to have the traffic between 1033, et cetera,
and 1044, et cetera, protected back and forth,
we need to also make sure we set up the routing.
And that, my friend, is exactly what we get to do
in the next video.
So I'll see you there in just a moment.