WEBVTT

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


2
00:00.900 --> 00:02.400 align:middle line:90%
In this video, you
and I get to chat

3
00:02.400 --> 00:05.310 align:middle line:90%
about the use of a
crypto map as far

4
00:05.310 --> 00:08.650 align:middle line:90%
as implementing IPSec
on our Cisco devices.

5
00:08.650 --> 00:12.510 align:middle line:90%
So for decades, we've used
IPSec to protect our IP packets

6
00:12.510 --> 00:15.450 align:middle line:90%
and one of the original
ways of implanting IPSec

7
00:15.450 --> 00:18.240 align:middle line:84%
was using a crypto map.

8
00:18.240 --> 00:20.490 align:middle line:90%
And the reason the
crypto map was so handy

9
00:20.490 --> 00:22.740 align:middle line:90%
was because we have
several parts and pieces

10
00:22.740 --> 00:23.920 align:middle line:84%
we need to all put together.

11
00:23.920 --> 00:26.850 align:middle line:90%
For example, if we want
to encrypt traffic that's

12
00:26.850 --> 00:31.470 align:middle line:90%
coming from 10.1.0 going
to 10.2.0 and vise versa,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

12
00:26.850 --> 00:31.470 align:middle line:90%
coming from 10.1.0 going
to 10.2.0 and vise versa,

13
00:31.470 --> 00:33.600 align:middle line:90%
if that's the traffic
we want to encrypt,

14
00:33.600 --> 00:37.570 align:middle line:90%
we need to specify that that
is the interesting traffic.

15
00:37.570 --> 00:40.140 align:middle line:90%
So we do that in the world
of crypto maps by creating

16
00:40.140 --> 00:42.690 align:middle line:90%
an access control list
and extended ACL that

17
00:42.690 --> 00:45.960 align:middle line:90%
has from R1's perspective,
10.1.0 as a source, 10.2.0

18
00:45.960 --> 00:48.195 align:middle line:90%
as the destination, and
from R2's perspective,

19
00:48.195 --> 00:52.020 align:middle line:90%
it would be 10.2.0 as a source
and 10.1.0 as the destination.

20
00:52.020 --> 00:55.770 align:middle line:90%
Also we'd want to specify for
the IPSec, the IKE phase 2

21
00:55.770 --> 00:57.500 align:middle line:90%
tunnel, improving
IKE version 1, we'd

22
00:57.500 --> 01:00.360 align:middle line:90%
want to specify what we
want to use for encryption,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

22
00:57.500 --> 01:00.360 align:middle line:90%
want to specify what we
want to use for encryption,

23
01:00.360 --> 01:03.540 align:middle line:90%
and also what we want to
use for the hashed message

24
01:03.540 --> 01:06.210 align:middle line:90%
authentication code
for data integrity.

25
01:06.210 --> 01:08.040 align:middle line:90%
And the way we do that
is we create what's

26
01:08.040 --> 01:10.830 align:middle line:90%
called an IPSec
transform set that

27
01:10.830 --> 01:13.840 align:middle line:90%
identifies the encryption and
the hashing we want to use.

28
01:13.840 --> 01:17.170 align:middle line:90%
And then what we do is we
take that transform set,

29
01:17.170 --> 01:20.590 align:middle line:90%
and also the crypto ACL, which
is what that ACL is called

30
01:20.590 --> 01:22.440 align:middle line:90%
that identifies the
interesting traffic,

31
01:22.440 --> 01:26.040 align:middle line:90%
and we bundle all of that
up into a crypto map.

32
01:26.040 --> 01:28.620 align:middle line:90%
So a crypto map is
like a container that

33
01:28.620 --> 01:32.580 align:middle line:90%
has the list of the engine
traffic and also the encryption
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

33
01:28.620 --> 01:32.580 align:middle line:90%
has the list of the engine
traffic and also the encryption

34
01:32.580 --> 01:34.830 align:middle line:90%
and hashing to use
for the IPSec tunnel.

35
01:34.830 --> 01:36.840 align:middle line:90%
The crypto map is
also going to include

36
01:36.840 --> 01:38.283 align:middle line:84%
the peer, who the peer is.

37
01:38.283 --> 01:40.200 align:middle line:90%
And then what we do is
we take that crypto map

38
01:40.200 --> 01:42.420 align:middle line:90%
and we apply it to an
interface, and then

39
01:42.420 --> 01:45.050 align:middle line:90%
when traffic is routed through
that interface or attempt

40
01:45.050 --> 01:46.800 align:middle line:90%
to be routed, the
router sees it and says,

41
01:46.800 --> 01:48.420 align:middle line:84%
oh, my gosh, everything matches.

42
01:48.420 --> 01:49.638 align:middle line:84%
The crypto ACL matches.

43
01:49.638 --> 01:51.930 align:middle line:90%
So I need to go ahead, and
if I don't have an IKE phase

44
01:51.930 --> 01:54.270 align:middle line:90%
1 tunnel, it'll build the
IKE phase 1 tunnel based

45
01:54.270 --> 01:55.470 align:middle line:84%
on who the peer should be.

46
01:55.470 --> 01:57.240 align:middle line:90%
It'll then build
IKE phase 2 tunnel,

47
01:57.240 --> 01:58.615 align:middle line:90%
and then it'll go
ahead and start

48
01:58.615 --> 02:00.870 align:middle line:90%
sending the traffic over the
IKE phase 2 tunnel, where
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

48
01:58.615 --> 02:00.870 align:middle line:90%
sending the traffic over the
IKE phase 2 tunnel, where

49
02:00.870 --> 02:03.090 align:middle line:90%
R1 encrypts it, R2
decrypts it and forwards it

50
02:03.090 --> 02:04.420 align:middle line:84%
onto its destination.

51
02:04.420 --> 02:08.400 align:middle line:90%
So that's a legacy method of
using IPSec or implementing

52
02:08.400 --> 02:08.910 align:middle line:84%
IPSec.

53
02:08.910 --> 02:11.490 align:middle line:90%
However, the command
Show Crypto Map

54
02:11.490 --> 02:13.500 align:middle line:90%
is still very useful
even if we're not

55
02:13.500 --> 02:15.030 align:middle line:90%
implementing crypto
maps, which I'll

56
02:15.030 --> 02:17.820 align:middle line:90%
talk about in the very
next video with VTIs.

57
02:17.820 --> 02:20.460 align:middle line:90%
And when we're implementing
IPSec tunnels with a crypto

58
02:20.460 --> 02:23.383 align:middle line:90%
map, as far as the
IPSec is concerned,

59
02:23.383 --> 02:25.050 align:middle line:90%
it's going to be in
tunnel mode if we're

60
02:25.050 --> 02:26.220 align:middle line:84%
doing it site the site.

61
02:26.220 --> 02:28.470 align:middle line:90%
Now tunnel node
simply means this.

62
02:28.470 --> 02:31.230 align:middle line:90%
We're taking the
original IP packet,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

62
02:28.470 --> 02:31.230 align:middle line:90%
We're taking the
original IP packet,

63
02:31.230 --> 02:34.440 align:middle line:90%
we're encrypting the whole
thing, we add a new ISP header,

64
02:34.440 --> 02:36.450 align:middle line:90%
and then we add
on a new IP header

65
02:36.450 --> 02:40.720 align:middle line:90%
that has the IP address of
R1 and R2 respectively in it.

66
02:40.720 --> 02:42.670 align:middle line:90%
And that is referred
to as tunnel mode.

67
02:42.670 --> 02:46.260 align:middle line:90%
And that's called tunnel mode,
because if this is the tunnel,

68
02:46.260 --> 02:48.732 align:middle line:90%
and we're going to shift
this traffic to the tunnel,

69
02:48.732 --> 02:50.190 align:middle line:90%
basically we're
wrapping it all up,

70
02:50.190 --> 02:53.010 align:middle line:90%
and we're carrying it over
this part of the network

71
02:53.010 --> 02:54.700 align:middle line:84%
in the new IP header.

72
02:54.700 --> 02:56.670 align:middle line:90%
So it's the actual
original payload

73
02:56.670 --> 03:00.120 align:middle line:90%
encrypted, encapsulated,
and carried over IPSec
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

73
02:56.670 --> 03:00.120 align:middle line:90%
encrypted, encapsulated,
and carried over IPSec

74
03:00.120 --> 03:01.235 align:middle line:84%
across this network.

75
03:01.235 --> 03:02.610 align:middle line:90%
And think of it
like that traffic

76
03:02.610 --> 03:03.652 align:middle line:84%
going through the tunnel.

77
03:03.652 --> 03:06.450 align:middle line:90%
The other option is transport
mode, and in transport mode,

78
03:06.450 --> 03:08.920 align:middle line:90%
we don't bother replacing
the outside header.

79
03:08.920 --> 03:12.390 align:middle line:90%
So in a site to site tunnel,
it will always be tunnel mode,

80
03:12.390 --> 03:15.330 align:middle line:90%
and that's the default for
IPSec for an IKE phase 2 tunnel.

81
03:15.330 --> 03:18.330 align:middle line:90%
Because if we didn't put on
the new headers for R1 and R2

82
03:18.330 --> 03:20.490 align:middle line:90%
as it crosses this
network, the internet

83
03:20.490 --> 03:22.770 align:middle line:90%
is not going to appreciate
having the source

84
03:22.770 --> 03:26.640 align:middle line:90%
and destination addresses
10.2 something 10.1 something

85
03:26.640 --> 03:29.560 align:middle line:90%
because those are private
RFC 19, 18 addresses.

86
03:29.560 --> 03:32.670 align:middle line:90%
So tunnel mode implies getting
a new header of VPN peers,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

86
03:29.560 --> 03:32.670 align:middle line:90%
So tunnel mode implies getting
a new header of VPN peers,

87
03:32.670 --> 03:36.360 align:middle line:90%
where transport implies don't
bother adding a new IP header.

88
03:36.360 --> 03:37.650 align:middle line:84%
Use the original addresses.

89
03:37.650 --> 03:39.150 align:middle line:90%
So in this video,
we've taken a look

90
03:39.150 --> 03:41.550 align:middle line:90%
at crypto maps, the
magical glue that

91
03:41.550 --> 03:43.770 align:middle line:90%
takes the crypto ACLs
and the transform sets

92
03:43.770 --> 03:46.270 align:middle line:90%
and everything else and
allows us to apply that crypto

93
03:46.270 --> 03:48.600 align:middle line:90%
map to an interface, which
tells the router, OK, I'll

94
03:48.600 --> 03:49.870 align:middle line:84%
pay attention to that traffic.

95
03:49.870 --> 03:52.020 align:middle line:90%
If I see it, I'll build the
tunnels, and I'll encrypt,

96
03:52.020 --> 03:53.062 align:middle line:84%
and I'll do what you say.

97
03:53.062 --> 03:57.180 align:middle line:90%
Now that used to be the game for
almost all IPSec VPN tunnels.

98
03:57.180 --> 04:01.320 align:middle line:90%
However, actually a long time
ago, we came out with the idea
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

98
03:57.180 --> 04:01.320 align:middle line:90%
However, actually a long time
ago, we came out with the idea

99
04:01.320 --> 04:04.050 align:middle line:90%
of, hey, why not use
tunnel interfaces,

100
04:04.050 --> 04:07.320 align:middle line:90%
like GRE tunnel interfaces, and
just tweak them a little bit

101
04:07.320 --> 04:09.360 align:middle line:90%
by putting IPSec
protection profiles

102
04:09.360 --> 04:11.110 align:middle line:84%
on those tunnel interfaces?

103
04:11.110 --> 04:12.900 align:middle line:90%
So that's what we do
a lot of times now,

104
04:12.900 --> 04:15.630 align:middle line:90%
and it beats the pants off of
using a traditional crypto map,

105
04:15.630 --> 04:18.329 align:middle line:90%
and we refer to that as a
virtual tunnel interface,

106
04:18.329 --> 04:19.310 align:middle line:84%
or VTI.

107
04:19.310 --> 04:21.459 align:middle line:90%
We'll take a closer look
at that in the next video.

108
04:21.459 --> 04:23.410 align:middle line:90%
So I'll see you there
in just a moment.

109
04:23.410 --> 04:25.920 align:middle line:90%
Meanwhile, I hope this has
been informative for you,

110
04:25.920 --> 04:29.180 align:middle line:90%
and I'd like to thank
you for viewing.