So in this video, now that we've configured everything,
let's verify that we have connectivity
from the 1033 network over here to the 1044 network over here.
That traffic should logically route it
over this tunnel interface.
And if it is, all traffic going over that tunnel
is protected with IPsec.
So our traffic as it goes from site three over to site four,
as it goes over this public network here,
should all be protected with IPsec.
So first let's verify basic connectivity
that's bringing up a couple VMs.
So here is the VM red on the left. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So here is the VM red on the left.
And here's the VM violet over here on the right.
And let's just verify they can ping each other.
Let's go ahead and verify their IP addresses.
We'll do IF config for either zero on both of them.
So on the left, this VM here has the IP address 10330152,
as shown right there.
And on the right, this little VM has the IP address 10440151.
So let's verify a ping.
So on the left, let's do a ping to 10.44.0.151 and press enter.
And that is working. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that is working.
Let's also do a ping over here from the right to 10.33.0.152,
press enter.
And that is also working.
So all that traffic between these two VMs
is logically being routed over this tunnel.
And that tunnel is being protected with IPsec.
So all that traffic in addition to being routed
over this logical tunnel is being protected with IPsec.
And for fun, let's do a quick little test.
So I'm going to do a control C on both sides to stop the ping.
I'll go ahead and also do an IF config again WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'll go ahead and also do an IF config again
just to verify what the IP address is involved are.
So on the left, it's 10330152.
And on the right, it's 10440151.
So to confirm the traffic is all being encrypted,
let me bring up a packet capture.
And let me tell my distributor switch at site three
that I want to go ahead and capture packets
and send them over to my management computer.
So here at site three, we'll go to our network tab here
in the vSphere client.
And let's go to our switch, which my edges are using.
And let's go to configure and go down to port mirroring. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And let's go to configure and go down to port mirroring.
And I currently have a session set up.
Let's take a look at the details.
We'll click on the three dots, click on edit.
And this is saying that we're taking traffic
from both of my edge nodes.
Now, only one of them is active,
but because I want to make sure I capture it,
I'm going to select both of them.
And for the destination, this is the destination IP address
of my management computer.
So we'll go back to edit properties.
And I want to enable this.
And I'm going to go ahead and enable that and click on OK.
So now that is sending data over to my management computer. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So now that is sending data over to my management computer.
And so that we can now see that data that's coming in,
let me bring up Wireshark.
So here is Wireshark.
And what I want to do is I want to collect the data coming in
on my ethernet interface.
And also, I'd like to do a little bit of filtering
and only collect packets that happen
to be going to IP protocol 47, which
is the protocol number four, GRE.
And that way, I don't have to have 20 or 30,000 packets
to look at.
I can just take a look at the ones that were sent to me
from the distributed switch.
So with that in place, we'll go ahead and enable that.
And here they come and let me make that full screen. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And here they come and let me make that full screen.
So if we grabbed any one of these packets
that the distributed switch is sending to me,
everything up to this point with GRE is just
the distributed switch shipping it over
to my management computer so we could take a look.
Also, for Grins, I'm going to put in a display filter
and put in ESP, which is protocol 50 being used
by IPsec.
So in the output here, it's only going to show traffic
if it is ESP traffic, meaning protocol 50,
IPsec protected traffic.
So let's bring back our two little VMs on the left. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let's bring back our two little VMs on the left.
I have the red VM on the right.
I have the violet VM.
And from the right to the left, let me go ahead
and do an SSH, do dash L for login as root.
And let's go over to the IP address of the right VM,
which is 10440151.
Also, before I press Enter here on the red VM on the left,
let me head over to the right VM here, the site for VM.
So we'll do a ping over to the IP address of the site 3 VM,
which is 10.33.0.152. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
which is 10.33.0.152.
And then I'll press Enter on both.
So we'll do an Enter there.
And on the VM on the left, I'll press Enter there.
And so one side is trying to SSH over,
the other side is trying to ping.
And so I'm going to go ahead and hit Cancel on both sides
because we've already caught our traffic
and let's take a look at the traffic.
So I'm going to go ahead and stop the capture.
I'm also going to go to the distributed switch
in the background and tell it to stop sending me that data
because we've got what we need.
So we'll click on Edit.
We'll stop the remote capture.
Click on Disabled there.
Click on OK.
So back at our capture, if we take a look at the traffic here, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So back at our capture, if we take a look at the traffic here,
all of it looks like it's going between 231230.
That's the global, readable address there
that we're using on the T0 gateway at site 3 and 241240,
which is the virtual IP address that we're using over at site 4.
So this is just traffic going back and forth between site 3
and site 4.
And if we look at the details here,
it's showing us that it is ESP.
So in the IP header, it's pointing to the next protocol
of 50, which is encapsulating security payload, effectively
IPsec.
And then we have the actual ESP payload. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then we have the actual ESP payload.
So it's anyways guessed now what's included in that payload.
Is it part of the ICMP traffic?
Or was the TCP-based traffic as part of an SSH session?
It's really tough to know because all that data is encrypted.
Also, check out these SPI numbers.
SPI stands for the Security Parameter Index.
Think of it like a numbering system
to identify an SAS Security Association used by IPsec.
So here we have the SPIs that are being used between those two
peers ending in 1, 0, 2, and 3, 0, 1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
peers ending in 1, 0, 2, and 3, 0, 1.
We can also verify that SPI number at the CLI for the edge nodes
who are actually doing the work of the IPsec tunnel between site
3 and site 4.
So if we go back to edge 2 and I timed out
Sol Press Enter to reconnect, is the active edge node,
or at least it was a few minutes ago when we looked at it?
So if we type in get IPsec VPN and a question mark,
and if we wanted to take a look, for example, at the IPsec
SA, short for Security Associations,
we can type in get IPsec VPN, IPsec SA, and press Enter. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we can type in get IPsec VPN, IPsec SA, and press Enter.
And that's going to show us our security associations.
And here at site 4--
and this is edge 2, which is the active edge node for site 4.
Here in the output of the command get IPsec VPN, IPsec
SA, which again, the SA is short for Security Association.
Here it has a session ID.
Here it's specifying exactly what's going to be encrypted.
So effectively, this has any IPv4 traffic that
goes over the tunnel is going to be encrypted.
And then if you continue to go down right here at the SPI in
and SPI out, take a look at those SPIs, those security WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and SPI out, take a look at those SPIs, those security
parameter index numbers.
We have one ending in 301, and we have one ending in 102.
And if we go back to our Wireshark capture,
that's reflected here as well.
We have one of them ending in 102 and one ending in 301.
So each peer has an inbound and an outbound security
association for IPsec.
It's also showing us the endpoints involved.
So from site 4's perspective, the local endpoint is 24, 120,
and the remote endpoint is 23, 120.
And here it's showing us the protocols that are used for WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And here it's showing us the protocols that are used for
that IPsec tunnel.
So if we modified or changed the profiles that we're using
for IPsec on both sides, we could also see the difference
right here at the CLI.
So because that would only take a moment to demonstrate,
let's do that as well.
This is the NSX manager for site 3.
So with networking selected, if we click here on VPN,
and then we'll click on IPsec sessions,
and let's edit our details that we're using over to site 4.
So we'll click on the three dots, click on edit,
and then we'll scroll down under advanced properties.
And then for the IPsec profiles, instead of using the default, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then for the IPsec profiles, instead of using the default,
let's go ahead and create a new one.
So we'll click on create new, and let's just go ahead
and change one value.
So instead of using AES GCM 128, let's go ahead
and use AES GCM 256.
And we'll click on save and click on save.
And that's done.
Let's make this similar change over at site 4.
So here in the NSX manager for site 4,
with networking selected, we'll get down to VPN.
We'll go to our IPsec sessions.
We'll edit our current existing IPsec session
by clicking on edit. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
by clicking on edit.
We'll scroll down to advanced.
And instead of using the default IPsec profile,
we'll click on the three dots and click on create new.
We'll call this our IPsec.
And then we're going to change the encryption algorithm.
And we'll set that to AES GCM 256.
And we'll get rid of the option of 128.
So if they both support like two or three,
and they have one common, they can negotiate and land on that.
But just to make it nice and clean,
I'm going to only give them one possibility on each side.
And that is the AES 256 flavor.
And with that selected, we'll click on save.
And then click on save. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then click on save.
And that says been updated successfully, fantastic.
So let me bring back my client on the right-hand side.
This is the site for Violet VM.
And let's try a quick ping.
And that ping is working.
That's great.
That implies that our tunnel is up and running.
I'll go into a control C to stop that.
And let's go back to the CLI at the edge node over at site 4.
So here at the edge node at site 4, a moment ago,
it said that we were using AES 128 GCM 16.
And now, if we hit the up arrow key and press enter, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And now, if we hit the up arrow key and press enter,
it should reflect.
And it is that we are now using AES 256,
as opposed to the earlier AES 128.
And the reason it's important to be aware of the CLI
is it's a great way to do step-by-step testing.
If we think something's happening, we want to confirm it.
We can go into the interface at the CLI
to the active edge node and just confirm it.
Also, as demonstrated, another great option
is to capture that traffic and take a look at it
to see what the actual content is of those packets.
Just to confirm that what we think is happening is happening. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Just to confirm that what we think is happening is happening.
Also in this output here, notice that the essay uptime
is only 44 seconds.
And that's because when we changed the parameters,
it had to renegotiate that tunnel.
And as a result, this is a brand new tunnel.
And that tunnel reflects the difference between
when the tunnel first came up and when I did the get command,
the getipsecvpn, ipsec essay command.
And another way to verify that our ipsec sessions
are up and active, of course, is through the NSX manager,
going through the networking tab.
And then under network services, click on VPN,
and then expand our existing ipsec sessions. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and then expand our existing ipsec sessions.
And then take a look at the details right here.
And if we click here on view statistics,
it can show us the details about the ipsec tunnel.
[BLANK_AUDIO]