WEBVTT

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


2
00:01.410 --> 00:02.440 align:middle line:84%
All right, my friend.

3
00:02.440 --> 00:03.210 align:middle line:84%
It is time.

4
00:03.210 --> 00:04.230 align:middle line:84%
Time for what?

5
00:04.230 --> 00:07.050 align:middle line:90%
It is time to verify
that what we configured

6
00:07.050 --> 00:10.930 align:middle line:90%
based on our IKEv2 and FlexVPN
that it's actually working.

7
00:10.930 --> 00:13.410 align:middle line:90%
So let's go to the
CLI, and let's verify.

8
00:13.410 --> 00:16.379 align:middle line:90%
All right, let's first of all,
start with the IKEv2 stuff.

9
00:16.379 --> 00:21.060 align:middle line:90%
Let's do a show crypto IKEv2,
and let's say proposal.

10
00:21.060 --> 00:24.370 align:middle line:90%
So based on our configuration,
we tweaked the default.

11
00:24.370 --> 00:27.660 align:middle line:90%
So here's what we offered for
encryption, data integrity,

12
00:27.660 --> 00:30.510 align:middle line:90%
the pseudorandom function, and
also the Diffie-Hellman group.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

12
00:27.660 --> 00:30.510 align:middle line:90%
the pseudorandom function, and
also the Diffie-Hellman group.

13
00:30.510 --> 00:32.729 align:middle line:90%
And hopefully, here's
what should happen,

14
00:32.729 --> 00:36.960 align:middle line:90%
if we negotiated a tunnel
successfully with R2,

15
00:36.960 --> 00:40.448 align:middle line:90%
we should be using for
IKEv2 Security Association

16
00:40.448 --> 00:41.490 align:middle line:84%
some of these parameters.

17
00:41.490 --> 00:43.960 align:middle line:90%
Hopefully the most secure
of these parameters.

18
00:43.960 --> 00:48.450 align:middle line:90%
So the way we verify that is
the show crypto, IKEv2, and SA.

19
00:48.450 --> 00:50.610 align:middle line:90%
And boom, that'll show us
our security association.

20
00:50.610 --> 00:52.410 align:middle line:84%
There it is.

21
00:52.410 --> 00:54.160 align:middle line:90%
I love it when a
plan comes together.

22
00:54.160 --> 00:56.520 align:middle line:90%
So this is showing the
local and remote IDs.

23
00:56.520 --> 01:00.660 align:middle line:90%
The 500 is UDP port 500,
which they used to negotiate.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

23
00:56.520 --> 01:00.660 align:middle line:90%
The 500 is UDP port 500,
which they used to negotiate.

24
01:00.660 --> 01:04.319 align:middle line:90%
And if we look at the
Encryption, it's using AES-256.

25
01:04.319 --> 01:06.390 align:middle line:90%
Great, that's right
from our proposal.

26
01:06.390 --> 01:07.930 align:middle line:84%
That's what we would expect.

27
01:07.930 --> 01:09.875 align:middle line:90%
And I notice that it's
using the most secure

28
01:09.875 --> 01:11.250 align:middle line:90%
of those that were
being offered,

29
01:11.250 --> 01:14.070 align:middle line:90%
and that were agreed to
during the initial exchange.

30
01:14.070 --> 01:17.250 align:middle line:90%
For hashing, we have
SHA512, which is represented

31
01:17.250 --> 01:18.673 align:middle line:84%
right here in our proposal.

32
01:18.673 --> 01:20.340 align:middle line:90%
And if we scroll a
little over to right,

33
01:20.340 --> 01:23.010 align:middle line:90%
here for the Diffie-Hellman
group, they chose 16.

34
01:23.010 --> 01:26.430 align:middle line:90%
And that's because we modified
the default IKEv2 proposal

35
01:26.430 --> 01:29.190 align:middle line:84%
to say, hey, we'll support 16.

36
01:29.190 --> 01:32.340 align:middle line:90%
It's also showing here that
they're using PSKs, Pre-Shared
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

36
01:29.190 --> 01:32.340 align:middle line:90%
It's also showing here that
they're using PSKs, Pre-Shared

37
01:32.340 --> 01:34.350 align:middle line:84%
Keys for the authentication.

38
01:34.350 --> 01:35.350 align:middle line:84%
Fantastic.

39
01:35.350 --> 01:40.010 align:middle line:90%
So that's the IKEv2 security
association as expected.

40
01:40.010 --> 01:42.810 align:middle line:90%
Next let's take a
look at the IPsec SA.

41
01:42.810 --> 01:47.797 align:middle line:90%
Let's do a show crypto, IPsec,
and let's do transform sets.

42
01:47.797 --> 01:49.380 align:middle line:90%
So we have a couple
of transform sets.

43
01:49.380 --> 01:51.120 align:middle line:90%
We have the default,
which we didn't use.

44
01:51.120 --> 01:54.060 align:middle line:90%
And we have our set, and
we included that inside

45
01:54.060 --> 01:56.260 align:middle line:84%
of an IPsec profile.

46
01:56.260 --> 02:01.860 align:middle line:90%
So we do a show crypto, IPsec
profile, spelled correctly.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

46
01:56.260 --> 02:01.860 align:middle line:90%
So we do a show crypto, IPsec
profile, spelled correctly.

47
02:01.860 --> 02:03.810 align:middle line:90%
This shows us our
IPsec profile here.

48
02:03.810 --> 02:07.650 align:middle line:90%
Our-v2-Profile, which
includes the transform set

49
02:07.650 --> 02:09.720 align:middle line:84%
called Our-Set.

50
02:09.720 --> 02:10.320 align:middle line:84%
Fantastic.

51
02:10.320 --> 02:12.810 align:middle line:90%
So if this was used,
we should actually

52
02:12.810 --> 02:15.810 align:middle line:90%
have a IPsec
security association

53
02:15.810 --> 02:17.780 align:middle line:84%
that's using these parameters.

54
02:17.780 --> 02:21.160 align:middle line:90%
And to verify that, we do
a show crypto, IPsec, SA.

55
02:21.160 --> 02:23.070 align:middle line:90%
And we're saying, hey,
Keith, this command

56
02:23.070 --> 02:24.997 align:middle line:90%
looks like the other
commands with IKEv1.

57
02:24.997 --> 02:26.580 align:middle line:90%
That's because it
is the same command.

58
02:26.580 --> 02:29.380 align:middle line:90%
We're talking about the
actual IPsec tunnel itself.

59
02:29.380 --> 02:32.373 align:middle line:90%
So currently we have
encaps and decaps of 0.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

59
02:29.380 --> 02:32.373 align:middle line:90%
So currently we have
encaps and decaps of 0.

60
02:32.373 --> 02:34.290 align:middle line:90%
So we're not using the
tunnel too effectively,

61
02:34.290 --> 02:35.950 align:middle line:84%
it would here at the moment.

62
02:35.950 --> 02:38.250 align:middle line:90%
And if we scroll
down, check this out.

63
02:38.250 --> 02:40.320 align:middle line:90%
Here it's showing us
the transforms involved,

64
02:40.320 --> 02:45.210 align:middle line:90%
they're AES-256 for encryption,
and SHA 512 for hashed message

65
02:45.210 --> 02:47.280 align:middle line:90%
authentication code
for data integrity.

66
02:47.280 --> 02:48.250 align:middle line:84%
Fantastic.

67
02:48.250 --> 02:50.447 align:middle line:90%
So there's an inbound
security association,

68
02:50.447 --> 02:52.280 align:middle line:90%
and there's an outbound
security association

69
02:52.280 --> 02:54.690 align:middle line:90%
is the two way street
with IPsec SEC.

70
02:54.690 --> 02:57.480 align:middle line:90%
Now the next question
is why are we

71
02:57.480 --> 02:59.520 align:middle line:90%
not encapsulating or
decapsulating traffic.

72
02:59.520 --> 03:02.550 align:middle line:90%
Another command,
this is pretty cool,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

72
02:59.520 --> 03:02.550 align:middle line:90%
Another command,
this is pretty cool,

73
03:02.550 --> 03:06.697 align:middle line:90%
even though we did not
configure crypto maps,

74
03:06.697 --> 03:08.280 align:middle line:90%
because we applied
a tunnel protection

75
03:08.280 --> 03:10.320 align:middle line:90%
profile on an
interface for IPsec,

76
03:10.320 --> 03:12.780 align:middle line:90%
we can still do the show
crypto map command is still

77
03:12.780 --> 03:14.010 align:middle line:84%
very, very useful.

78
03:14.010 --> 03:15.390 align:middle line:84%
Check this out.

79
03:15.390 --> 03:18.990 align:middle line:90%
So we do a show crypto
map, and press Enter.

80
03:18.990 --> 03:21.093 align:middle line:90%
Here it's showing
us that on tunnel 0,

81
03:21.093 --> 03:22.260 align:middle line:84%
it's showing us the details.

82
03:22.260 --> 03:25.380 align:middle line:90%
Here's our peer, there's the
transform set and use, just

83
03:25.380 --> 03:27.300 align:middle line:90%
another way to peek
at the information,

84
03:27.300 --> 03:29.730 align:middle line:90%
even though we didn't
literally apply a crypto map.

85
03:29.730 --> 03:32.310 align:middle line:90%
Another interesting note here,
if we didn't use tunnel mode
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

85
03:29.730 --> 03:32.310 align:middle line:90%
Another interesting note here,
if we didn't use tunnel mode

86
03:32.310 --> 03:34.320 align:middle line:90%
IPsec on the tunnel
interface, it also

87
03:34.320 --> 03:36.660 align:middle line:90%
would show here that
the entering traffic

88
03:36.660 --> 03:41.350 align:middle line:90%
is GRE traffic as opposed
to just IPsec natively.

89
03:41.350 --> 03:43.980 align:middle line:90%
So let's solve the next
problem of why are we

90
03:43.980 --> 03:45.970 align:middle line:90%
not encrypting or
decrypting any traffic.

91
03:45.970 --> 03:49.000 align:middle line:90%
So show crypto, IPsec,
SA, and sure enough,

92
03:49.000 --> 03:51.940 align:middle line:90%
it says encaps and
decaps nada, zero, zippo.

93
03:51.940 --> 03:55.380 align:middle line:84%


94
03:55.380 --> 04:00.000 align:middle line:90%
Let's do a show IP route,
and that would explain it.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

95
04:00.000 --> 04:01.210 align:middle line:84%
That would explain it.

96
04:01.210 --> 04:04.410 align:middle line:90%
So the problem here is that
we have a great IKEv2 security

97
04:04.410 --> 04:04.950 align:middle line:84%
association.

98
04:04.950 --> 04:07.230 align:middle line:90%
We checked that, out
matches our policy.

99
04:07.230 --> 04:09.960 align:middle line:90%
We have a great IPsec
SA, we checked it out.

100
04:09.960 --> 04:12.990 align:middle line:90%
But the reason it's not being
used to encrypt or decrypt

101
04:12.990 --> 04:15.240 align:middle line:90%
traffic, is because
the tunnel interface

102
04:15.240 --> 04:17.683 align:middle line:90%
from the routing table
isn't used for anything.

103
04:17.683 --> 04:19.100 align:middle line:90%
It's not even in
the routing table

104
04:19.100 --> 04:20.490 align:middle line:84%
as far forwarding packets.

105
04:20.490 --> 04:22.803 align:middle line:90%
So to solve this, we
need to add some routing.

106
04:22.803 --> 04:24.220 align:middle line:90%
So that the router
will feel like,

107
04:24.220 --> 04:26.740 align:middle line:90%
oh, I need a forward traffic
through that tunnel interface,

108
04:26.740 --> 04:29.730 align:middle line:90%
so that the encryption can go
ahead and be done and protect

109
04:29.730 --> 04:30.700 align:middle line:84%
that traffic.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

109
04:29.730 --> 04:30.700 align:middle line:84%
that traffic.

110
04:30.700 --> 04:33.010 align:middle line:90%
So we'll address routing
in the next video.

111
04:33.010 --> 04:34.900 align:middle line:90%
So I'll see you there
in just a moment.

112
04:34.900 --> 04:37.320 align:middle line:90%
Meanwhile, I hope this has
been informative for you,

113
04:37.320 --> 04:40.460 align:middle line:90%
and I'd like to thank
you for viewing.