So now that we have these two segments associated with our layer 2 VPN service,
we should now have the ability to communicate back and forth between these two
VMs.
In fact, when I left it, I had this VM here trying to ping this VM and vice
versa.
So let me bring back those remote console windows.
So here is the site 4 VM right here,
and those pings are flying now, fantastic.
Here is the site 3 VM right here,
just a little bit on the left-hand side.
If we were to capture this traffic,
what we would see is traffic going back and forth between these two endpoint IP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
what we would see is traffic going back and forth between these two endpoint IP
addresses,
and the payload would be ESP, which is protocol 50, which is used by IPsec.
Implying that that traffic is encrypted,
so whether we're doing pings or SSH or Telnet or HTTP traffic back and forth,
as it goes over the transport network, all that traffic is encrypted.
Also, to verify the path to the network, let's go ahead and do a trace,
and we can do this from either site 3 or site 4.
Let's do a trace just to verify the path and the logic that's being done on a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Let's do a trace just to verify the path and the logic that's being done on a
packet,
trying to leave this VM as it's going out to this VM.
Now, because I have two separate NSX managers,
and I don't have an NSX federation set up or anything else,
we're not going to have one NSX manager that's going to show us the whole
picture.
So for our test here from site 3,
let's use the trace little feature in the NSX manager,
and let's do a trace from this VM here to the IP address
that's currently being used by this VM right here.
And that'll each show us this half of the story.
So let me go ahead and stop my ping there for a moment, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let me go ahead and stop my ping there for a moment,
and then we confirm the IP address on each side.
So at site 4 here, the IP address of this VM is 1099.041.
So what we'll do in trace flow here at the NSX manager for site 3
is that we'll look at traffic from this VM going to that IP address.
So here in light mode in the site 3 NSX manager,
we'll go to plan and troubleshoot, and on the left,
we'll click on traffic analysis.
And then we'll click on the get started here in the tile for trace flow.
And then here in trace flow, we'll specify the source machine WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then here in trace flow, we'll specify the source machine
is our site 3 red VM,
and just to confirm it's IP address, that looks good.
And for the destination, which is in the other site,
instead of specifying a virtual machine,
we'll specify IP address, specify layer 3 only,
and we'll specify the IP address of 10.99.0.41,
which is the IP address that the VM over at site 3 is currently using.
We'll scroll down and we'll click on trace.
And then we'll give it a minute to go ahead and run that.
All right, and here are the results. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
All right, and here are the results.
So ESXi Red 1 must be the host that's hosting our little VM at site 3,
because that's the host involved here.
So it went through the logic of the distributed firewall rules.
It did the logical switching through segment 99.
It then did the logical distributed routing decisions
through the T0 distributed router.
And then it handed it off to an edge node.
So this is ESXi Red 1.
And so there's the tunnel endpoint addresses.
And then edge 2 did some processing with it
through that logical segment of site 99, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
through that logical segment of site 99,
including logical processing through the T0 gateway.
And then it went through the process of IPsec,
which it encrypted traffic and shipped it off
to the next device in the path,
which would be an edge node over at site 4.
So this is showing us from the site 3 perspective,
all the logic that's being done.
So with the trace flow being used here at site 3,
you could identify that first part of the journey
from the host that was hosting that VM to the local edge,
which then used an IPsec tunnel to forward it
to the next top of the path,
which was the active edge node here at site 4, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
which was the active edge node here at site 4,
who would then decrypt it and then forward it down
to the tunnel endpoint to the local host,
where the traffic would finally then be delivered.
Also, just for fun, as we send traffic back and forth
between these two VMs,
let's also capture the traffic here on the transport network,
just to verify that it's ESP protected traffic,
going to and from the 23, 1, 230 address
and the 24, 1, 240 address,
as the IPsec tunnel is used
between the two respective edge nodes.
So I'm gonna go ahead on the 2VMs
and you start up ping back and forth between them. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and you start up ping back and forth between them.
And with that running, I'll go to a distributed switch
and ask it to do a capture
and send it all right here to our management computer.
So here is the vSphere client for site 3,
that'll work and let's go to the networking tab.
We'll go to the distributed switch that my edges are using,
and I currently have port marrying set up.
It's disabled at the moment, let me just confirm it's settings.
So the source is the two edge nodes,
fantastic and the destination is my management computer.
So we'll edit that and we'll simply say,
please start and okay.
So now it's capturing that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So now it's capturing that
and shipping it over to my management computer.
All right, and here we go.
So there's a whole bunch of traffic going on.
And let's just filter it down with a display filter
and say we only wanna see ESP traffic
and this represents the ESP traffic currently happening.
So if we brought back our clients real quick,
it's just to confirm that the ESP traffic
is being caused by these clients.
Let me go ahead and let me go ahead and stop that for a moment.
We'll do a control C at the VM at site 3
and a control C, the VM at site 4.
You'll notice that the packets have stopped. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
You'll notice that the packets have stopped.
So if we send traffic back and forth between these two VMs,
that traffic is being encrypted and encapsulated
by the edge nodes at those respective sites
before it's being sent to the peer at the other side.
So here in the output, everything up to
and including the GRE encapsulation,
is just the distributed switch
sending it over to my management computer.
And then being carried in that
is the actual traffic that it got off the wire.
There's the IPv4 header.
And if we take a look at the details of that
and I scooch up a little bit here.
In the layer three header, we have the IP addresses
for the respective edge nodes that they're using WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for the respective edge nodes that they're using
as part of the TR0 gateway at site 4 and 3 respectively.
As far as the payload goes, it's protocol 50
and then we have the ESP.
So behind the scenes, this could be almost anything.
It could be HTTPS traffic, SSH traffic,
ping traffic, ICB traffic.
As that traffic goes over the transport network
and is protected by ESP, we really don't know
what's in there or what the original IP addresses are
because it's all encrypted and protected.
Now, because I was capturing data
off of the transport network,
I'm also capturing traffic as it goes between WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'm also capturing traffic as it goes between
the host tunnel endpoints and the edge tunnel endpoints
at site 3.
So if we changed our display filter, for example,
and said, I want to see ICMP traffic and press Enter,
once getting up to this point,
it's just the distributed switch saying the traffic
over to my management computer.
And then the next header here is the IP addresses
for my host and edge nodes at site 3.
With the layer 4 protocol of UDP,
with the well-known port for Geniv,
then we have the Geniv information. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
then we have the Geniv information.
And then within that, we have the original data packets
who are being sent.
So this case, it's an ICMP message from 1099-041,
which is our site for to the virtual machine address
at site 3.
And if we open up the details for ICMP,
it's showing us exactly what this is.
So this is a reply to an ICMP ping request.
And the reason we can see all of this here unencrypted
is because the traffic that's in your traffic being sent.
From an edge node at site 3, over to a host at site 3,
that traffic isn't encrypted. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that traffic isn't encrypted.
However, the traffic that's going between the two sites,
from the edge nodes at site 3 and the edge nodes at site 4,
that traffic is being encrypted.
So once again, if we put a display filter
for looking just for ESP traffic,
it's going to show us just that encapsulated traffic.
And this would be the traffic going between the two sites.
And earlier at the active edge node,
which was edge 2 at site 4, we use this command.
I've timed out due to inactivity.
So let me go ahead and reestablish that connection.
And let me also go ahead and start generating
some additional traffic from the two VMs, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
some additional traffic from the two VMs,
one at site 3 and one at site 4.
And let's go ahead and run that command again.
And in the output here, the number of received and sent packets
regarding the LTVPN should be increasing.
And because the pings are still running,
if I hit the upper key and press enter,
those numbers should continue to increase.
So in conjunction with the LTVPN,
we also have our IPsec VPN.
So we do a get IPsec VPN.
And if we want to take a look at the details
for the actual IPsec tunnel itself,
we can tack on IPsecSA,
which is short for security association and press enter. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
which is short for security association and press enter.
So there's the command we just issued.
Here are the tunnel endpoints between site 4 and site 3.
And here's the encryption, hashing
and Diffie-Hellman group reusing and combination
with our IPsec tunnel.