The fun continues.
Now that we've done the work, let's
use some protocol analysis just to verify
the behavior of the packets before,
during, and after their trip over the tunnel.
So for this test, I've generated some web traffic from PC1.
That traffic hits the router.
The router says, oh, the route's through the tunnel interface
before it exits, because the tunnel protection profile
for IPsec, it encrypts that traffic
and now it ships it over to R2.
So all we should see here is ESP,
which is protocol 50 at layer 4 and then WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
which is protocol 50 at layer 4 and then
the payload is all just a bunch of encrypted nightmare.
Then R2-- it's a nightmare if you're in the cloud,
and you don't have the correct keys,
but R2 decrypts that and then forward the packet to PC 2,
who then replies, and that process is
repeated the other direction.
So we're going to capture at point a, point b, and point c,
just to verify the details of what we can or can't see
at each of those three points.
So this is point a, and the network on the 10.1 network,
and I used a capture based on the identifier
for this specific packet of hexadecimal 4965. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for this specific packet of hexadecimal 4965.
I put that up in the display filter,
and what this appears to be is http.
So it looks down here like the get request.
That sounds great, so it's sourced from 38,592.
That was chosen by PC1, sent to the well-known port of 80.
That looks all great, and this then was sent to the router.
Then when the router got that, because of its routing it
through the tunnel interface, it did the IPsec to protect it,
and that's what it looked like right here.
In fact, I can't-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
In fact, I can't--
I guess we could guess based on the size of the packet,
including a little bit of overhead for IPsec,
but it's pretty tough to determine
what these packets are carrying, because it
says that at layer 3, it points to protocol 50, which is ESP,
and then as far as the ESP goes, there
are some, the SPI information that's there, but as far as
the payload, I have no idea.
Payload that's encrypted now as it goes over the network.
Now that same packet, as it emerges at the far side,
would be received by R2, who decrypts it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
would be received by R2, who decrypts it
and then forwards it on its way, and it would look like this.
And so this is the same packet, same packet identifier,
after it's made its trip over to R2
and after our R2's deencrypted and deencapsulated it.
So it's the same packet, same data,
except if we look at the time to live, the time to live here
is 62, and over at site one, when
it left, let's take a peek at that,
the time to live in the layer three header was 64.
So as the routers are propagating that,
they're decorating the time to live
as they forward the packet. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I would like to thank you for joining me in these videos,
and I look forward to seeing you in the next set of videos.
Until then, I hope this has been informative for you,
and I'd like to thank you for viewing.