WEBVTT

1
00:00.000 --> 00:01.480 align:middle line:84%


2
00:01.480 --> 00:02.362 align:middle line:84%
The fun continues.

3
00:02.362 --> 00:03.820 align:middle line:90%
Now that we've done
the work, let's

4
00:03.820 --> 00:06.430 align:middle line:90%
use some protocol
analysis just to verify

5
00:06.430 --> 00:08.630 align:middle line:90%
the behavior of
the packets before,

6
00:08.630 --> 00:11.960 align:middle line:90%
during, and after their
trip over the tunnel.

7
00:11.960 --> 00:14.980 align:middle line:90%
So for this test, I've generated
some web traffic from PC1.

8
00:14.980 --> 00:16.398 align:middle line:84%
That traffic hits the router.

9
00:16.398 --> 00:18.940 align:middle line:90%
The router says, oh, the route's
through the tunnel interface

10
00:18.940 --> 00:21.250 align:middle line:90%
before it exits, because the
tunnel protection profile

11
00:21.250 --> 00:23.260 align:middle line:90%
for IPsec, it
encrypts that traffic

12
00:23.260 --> 00:25.190 align:middle line:84%
and now it ships it over to R2.

13
00:25.190 --> 00:27.940 align:middle line:90%
So all we should
see here is ESP,

14
00:27.940 --> 00:30.220 align:middle line:90%
which is protocol 50
at layer 4 and then
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

14
00:27.940 --> 00:30.220 align:middle line:90%
which is protocol 50
at layer 4 and then

15
00:30.220 --> 00:33.430 align:middle line:90%
the payload is all just a
bunch of encrypted nightmare.

16
00:33.430 --> 00:35.860 align:middle line:90%
Then R2-- it's a nightmare
if you're in the cloud,

17
00:35.860 --> 00:37.360 align:middle line:90%
and you don't have
the correct keys,

18
00:37.360 --> 00:41.830 align:middle line:90%
but R2 decrypts that and then
forward the packet to PC 2,

19
00:41.830 --> 00:43.390 align:middle line:90%
who then replies,
and that process is

20
00:43.390 --> 00:44.960 align:middle line:84%
repeated the other direction.

21
00:44.960 --> 00:49.240 align:middle line:90%
So we're going to capture at
point a, point b, and point c,

22
00:49.240 --> 00:51.860 align:middle line:90%
just to verify the details
of what we can or can't see

23
00:51.860 --> 00:53.290 align:middle line:84%
at each of those three points.

24
00:53.290 --> 00:55.900 align:middle line:90%
So this is point a, and the
network on the 10.1 network,

25
00:55.900 --> 00:58.660 align:middle line:90%
and I used a capture
based on the identifier

26
00:58.660 --> 01:02.530 align:middle line:90%
for this specific packet
of hexadecimal 4965.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

26
00:58.660 --> 01:02.530 align:middle line:90%
for this specific packet
of hexadecimal 4965.

27
01:02.530 --> 01:04.480 align:middle line:90%
I put that up in
the display filter,

28
01:04.480 --> 01:07.710 align:middle line:90%
and what this appears
to be is http.

29
01:07.710 --> 01:09.760 align:middle line:90%
So it looks down here
like the get request.

30
01:09.760 --> 01:13.990 align:middle line:90%
That sounds great, so
it's sourced from 38,592.

31
01:13.990 --> 01:17.710 align:middle line:90%
That was chosen by PC1, sent
to the well-known port of 80.

32
01:17.710 --> 01:21.640 align:middle line:90%
That looks all great, and this
then was sent to the router.

33
01:21.640 --> 01:24.310 align:middle line:90%
Then when the router got that,
because of its routing it

34
01:24.310 --> 01:27.250 align:middle line:90%
through the tunnel interface,
it did the IPsec to protect it,

35
01:27.250 --> 01:29.000 align:middle line:90%
and that's what it
looked like right here.

36
01:29.000 --> 01:30.670 align:middle line:84%
In fact, I can't--
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

36
01:29.000 --> 01:30.670 align:middle line:84%
In fact, I can't--

37
01:30.670 --> 01:33.250 align:middle line:90%
I guess we could guess based
on the size of the packet,

38
01:33.250 --> 01:35.150 align:middle line:90%
including a little bit
of overhead for IPsec,

39
01:35.150 --> 01:37.180 align:middle line:90%
but it's pretty
tough to determine

40
01:37.180 --> 01:39.400 align:middle line:90%
what these packets are
carrying, because it

41
01:39.400 --> 01:43.660 align:middle line:90%
says that at layer 3, it points
to protocol 50, which is ESP,

42
01:43.660 --> 01:46.060 align:middle line:90%
and then as far as
the ESP goes, there

43
01:46.060 --> 01:49.840 align:middle line:90%
are some, the SPI information
that's there, but as far as

44
01:49.840 --> 01:51.690 align:middle line:84%
the payload, I have no idea.

45
01:51.690 --> 01:54.700 align:middle line:90%
Payload that's encrypted now
as it goes over the network.

46
01:54.700 --> 01:58.120 align:middle line:90%
Now that same packet, as
it emerges at the far side,

47
01:58.120 --> 02:01.000 align:middle line:90%
would be received by
R2, who decrypts it
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

47
01:58.120 --> 02:01.000 align:middle line:90%
would be received by
R2, who decrypts it

48
02:01.000 --> 02:04.010 align:middle line:90%
and then forwards it on its way,
and it would look like this.

49
02:04.010 --> 02:06.970 align:middle line:90%
And so this is the same
packet, same packet identifier,

50
02:06.970 --> 02:09.550 align:middle line:90%
after it's made
its trip over to R2

51
02:09.550 --> 02:12.960 align:middle line:90%
and after our R2's deencrypted
and deencapsulated it.

52
02:12.960 --> 02:15.040 align:middle line:90%
So it's the same
packet, same data,

53
02:15.040 --> 02:17.830 align:middle line:90%
except if we look at the time
to live, the time to live here

54
02:17.830 --> 02:20.350 align:middle line:90%
is 62, and over
at site one, when

55
02:20.350 --> 02:22.170 align:middle line:90%
it left, let's take
a peek at that,

56
02:22.170 --> 02:25.210 align:middle line:90%
the time to live in the
layer three header was 64.

57
02:25.210 --> 02:27.260 align:middle line:90%
So as the routers
are propagating that,

58
02:27.260 --> 02:28.780 align:middle line:90%
they're decorating
the time to live

59
02:28.780 --> 02:30.000 align:middle line:84%
as they forward the packet.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

60
02:30.000 --> 02:32.500 align:middle line:90%
So I would like to thank you
for joining me in these videos,

61
02:32.500 --> 02:34.540 align:middle line:90%
and I look forward to seeing
you in the next set of videos.

62
02:34.540 --> 02:36.970 align:middle line:90%
Until then, I hope this has
been informative for you,

63
02:36.970 --> 02:40.450 align:middle line:90%
and I'd like to thank
you for viewing.