WEBVTT

1
00:00.000 --> 00:06.610
So the first thing you want to do usually is make sure there's no other

2
00:06.610 --> 00:07.540
debugging going

3
00:07.540 --> 00:09.040
on.

4
00:09.040 --> 00:11.440
You can do this with a show debug.

5
00:11.440 --> 00:16.080
We see here that there's currently no debug's active on this router.

6
00:16.080 --> 00:21.120
If your SSH into the device, you also want to make sure that you've turned on

7
00:21.120 --> 00:21.840
terminal

8
00:21.840 --> 00:22.840
monitor.

9
00:22.840 --> 00:26.400
I already have that on as part of my login script.

10
00:26.400 --> 00:30.480
But if you don't, make sure you enable this or else you won't see the debug
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

10
00:26.400 --> 00:30.480
But if you don't, make sure you enable this or else you won't see the debug

11
00:30.480 --> 00:31.420
messages in

12
00:31.420 --> 00:33.200
the terminal session.

13
00:33.200 --> 00:35.680
So next let's turn on our debug.

14
00:35.680 --> 00:39.600
So let's start with doing a debug crypto like V2.

15
00:39.600 --> 00:43.480
You can see here what we mean by the fact that it's in real time because these

16
00:43.480 --> 00:44.120
messages

17
00:44.120 --> 00:47.120
are of course going past as we look at it.

18
00:47.120 --> 00:50.040
So we know that this is working.

19
00:50.040 --> 00:55.450
If we wanted to see the initial messages, we could go into tunnel one, do a

20
00:55.450 --> 00:56.560
shutdown on

21
00:56.560 --> 00:58.120
the tunnel.

22
00:58.120 --> 01:02.740
We see the tunnel just went down and we can do a no shut to bring that tunnel
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

22
00:58.120 --> 01:02.740
We see the tunnel just went down and we can do a no shut to bring that tunnel

23
01:02.740 --> 01:03.560
back up.

24
01:03.560 --> 01:06.550
Now in case you're wondering if they haven't hit enter yet, remember that we

25
01:06.550 --> 01:08.480
have two tunnels.

26
01:08.480 --> 01:12.440
So the debug's we're seeing right now are from tunnel two.

27
01:12.440 --> 01:15.220
So we'll give it just a second to do a three fresh there and then let's hit

28
01:15.220 --> 01:15.800
enter to bring

29
01:15.800 --> 01:17.840
our tunnel back up.

30
01:17.840 --> 01:21.040
And you can see a lot of information went by there.

31
01:21.040 --> 01:25.780
I'm going to do a U all for an undi bug all to turn off the debugging and then

32
01:25.780 --> 01:26.160
we can

33
01:26.160 --> 01:28.120
scroll back through.

34
01:28.120 --> 01:31.400
So we're certainly not going to go through all of this because there is a ton
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

34
01:28.120 --> 01:31.400
So we're certainly not going to go through all of this because there is a ton

35
01:31.400 --> 01:32.200
of information

36
01:32.200 --> 01:34.200
here that happens.

37
01:34.200 --> 01:38.260
But you can see here from the time I said no shut where it matched on the fact

38
01:38.260 --> 01:38.560
that

39
01:38.560 --> 01:41.760
it was going to bring up a peer block AWS tunnel one.

40
01:41.760 --> 01:43.760
That's just because that's what I named it.

41
01:43.760 --> 01:48.040
It identifies the policy it's going to use for the local address.

42
01:48.040 --> 01:52.300
It then computes the Diffie-Hellman public key, the group type, sends the

43
01:52.300 --> 01:53.120
information

44
01:53.120 --> 01:54.520
out.

45
01:54.520 --> 01:59.280
Notice here where we're actually sending the packet out to our peer.

46
01:59.280 --> 02:04.080
Notice that it already has an initiator SPI because that's our SPI.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

46
01:59.280 --> 02:04.080
Notice that it already has an initiator SPI because that's our SPI.

47
02:04.080 --> 02:08.360
But it doesn't know the responder SPI yet because they have an answered and we

48
02:08.360 --> 02:08.980
're doing

49
02:08.980 --> 02:11.200
an exchange request.

50
02:11.200 --> 02:12.200
Scrolling down some.

51
02:12.200 --> 02:16.080
Again, we can see there's a lot of information happening here.

52
02:16.080 --> 02:19.560
We're not going to go over every single piece of it, like I said.

53
02:19.560 --> 02:25.600
But we are now, however, receiving our packet back from AWS and notice that now

54
02:25.600 --> 02:26.240
we have

55
02:26.240 --> 02:32.540
the initiator and the responder SPI because these two have now spoken to each
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

55
02:26.240 --> 02:32.540
the initiator and the responder SPI because these two have now spoken to each

56
02:32.540 --> 02:32.920
other.

57
02:32.920 --> 02:37.780
Just to point out some of the information as we scroll down, notice these three

58
02:37.780 --> 02:38.240
lines

59
02:38.240 --> 02:43.150
right here is where it just detected that we are in fact using NAT and

60
02:43.150 --> 02:44.360
therefore changes

61
02:44.360 --> 02:47.680
the port over to 4,500.

62
02:47.680 --> 02:50.880
This isn't doing the NAT traversal right here.

63
02:50.880 --> 02:54.180
Scrolling down a little bit more, there's a bunch of messages right here and we

64
02:54.180 --> 02:54.640
're sure

65
02:54.640 --> 02:57.680
as heck not going to discuss each and every one of them.

66
02:57.680 --> 03:01.880
But notice that it's changing a lot of attribute types.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

66
02:57.680 --> 03:01.880
But notice that it's changing a lot of attribute types.

67
03:01.880 --> 03:05.960
There's a lot of different sections here that are talking about attributes.

68
03:05.960 --> 03:10.790
This is the two sides exchanging their capabilities and attributes that are set

69
03:10.790 --> 03:11.680
on the IKE version

70
03:11.680 --> 03:13.600
two messages.

71
03:13.600 --> 03:16.500
Little further down here, you see where it decides that it's supposed to use

72
03:16.500 --> 03:16.960
pre shared

73
03:16.960 --> 03:18.680
key for this.

74
03:18.680 --> 03:22.240
It sees that it's supposed to be using pre shared key.

75
03:22.240 --> 03:27.440
And notice right here is where it starts to do the ESP proposals and the IPsec

76
03:27.440 --> 03:28.680
negotiation.

77
03:28.680 --> 03:33.240
A little further down, we see that it gets the response coming in from the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

77
03:28.680 --> 03:33.240
A little further down, we see that it gets the response coming in from the

78
03:33.240 --> 03:34.040
other side.

79
03:34.040 --> 03:36.200
That would be AWS.

80
03:36.200 --> 03:38.800
We see it checking all of the information.

81
03:38.800 --> 03:41.600
We see it processing the authentication.

82
03:41.600 --> 03:42.800
It found the policy.

83
03:42.800 --> 03:46.240
It verified the peers policy sees that everything is good.

84
03:46.240 --> 03:50.660
It gets the peers pre shared key, verifies the authentication and then the IKEV

85
03:50.660 --> 03:51.880
2 authentication

86
03:51.880 --> 03:55.080
engine generation has passed.

87
03:55.080 --> 03:59.740
A little further down, we see the last couple phases of this where it actually

88
03:59.740 --> 04:00.640
initializes
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

88
03:59.740 --> 04:00.640
initializes

89
04:00.640 --> 04:04.920
the DPD to keep the tunnel up and going.

90
04:04.920 --> 04:10.400
And here we see that it successfully created the IPsec SA into the IPsec

91
04:10.400 --> 04:12.800
database has passed

92
04:12.800 --> 04:14.960
and the tunnel comes up.

93
04:14.960 --> 04:18.000
So again, there's a lot of information going on here.

94
04:18.000 --> 04:21.320
We certainly just did a skim over this information.

95
04:21.320 --> 04:24.760
But as you can see, it is a ton of information.

96
04:24.760 --> 04:27.120
Very, very useful for troubleshooting.

97
04:27.120 --> 04:30.650
But all in all, this is what this should look like when it comes up
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

97
04:27.120 --> 04:30.650
But all in all, this is what this should look like when it comes up

98
04:30.650 --> 04:31.680
successfully.

99
04:31.680 --> 04:37.160
Next, let's turn on debugging for crypto IPsec.

100
04:37.160 --> 04:39.960
And once again, let's shut down our tunnel.

101
04:39.960 --> 04:43.860
We can actually see when we do the shutdown there of it releasing all of the

102
04:43.860 --> 04:44.440
keys that

103
04:44.440 --> 04:48.000
it had previously because I shut down the tunnel.

104
04:48.000 --> 04:52.130
And now if we do a no shut to bring it back up, we'll turn off our debugging

105
04:52.130 --> 04:52.760
again.

106
04:52.760 --> 04:56.710
If we scroll back up to where we did our no shut, we can see it's going to be

107
04:56.710 --> 04:57.000
sending

108
04:57.000 --> 05:00.000
the messages between the two devices.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

109
05:00.000 --> 05:03.910
Here we see the parameters that's going to be using for the negotiation using

110
05:03.910 --> 05:04.840
ESP specifically

111
05:04.840 --> 05:07.960
ESP GCM 256.

112
05:07.960 --> 05:12.000
So essentially, this is all of the information in the outbound request.

113
05:12.000 --> 05:13.920
A little bit further down here.

114
05:13.920 --> 05:19.280
We actually see the inbound message coming in from the remote side.

115
05:19.280 --> 05:24.280
We see here the parameters for the tunnel match on that inbound message.

116
05:24.280 --> 05:29.040
We see a little further down at the proposal for the tunnel was accepted.

117
05:29.040 --> 05:34.040
It's going to be using tunnel one as the head end for the mapping for the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

117
05:29.040 --> 05:34.040
It's going to be using tunnel one as the head end for the mapping for the

118
05:34.040 --> 05:34.040
traffic.

119
05:34.040 --> 05:38.440
Going between these two addresses, which of course, it pulled from the tunnel.

120
05:38.440 --> 05:42.360
Just in case you haven't picked up on where the local and remotes coming from,

121
05:42.360 --> 05:45.000
local is the source address of the tunnel.

122
05:45.000 --> 05:47.880
Remote is the destination address of the tunnel.

123
05:47.880 --> 05:52.440
And of course, those addresses have to match all of our IPsec and

124
05:52.440 --> 05:54.960
like version two proposals and such.

125
05:54.960 --> 05:59.310
That's how it's matching these things up is based off the addresses on the

126
05:59.310 --> 06:00.160
tunnels.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

126
05:59.310 --> 06:00.160
tunnels.

127
06:00.160 --> 06:03.600
You can see that a little further down here when it's accepting that map coming

128
06:03.600 --> 06:03.800
from

129
06:03.800 --> 06:08.120
tunnel one, it found the map down here for tunnel one.

130
06:08.120 --> 06:11.360
And it knows who the peer is for that tunnel.

131
06:11.360 --> 06:15.040
Now once again, there's a lot of information here if we scroll down through it.

132
06:15.040 --> 06:20.000
But ultimately what we're looking for, of course, is the tunnel coming up and

133
06:20.000 --> 06:24.640
that there are no errors shown here in any of the debug.

134
06:24.640 --> 06:29.720
So in this video, we took a look at some really good show commands and

135
06:29.720 --> 06:36.070
some good debug commands to see what's going on when our IPsec VPN is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

135
06:29.720 --> 06:36.070
some good debug commands to see what's going on when our IPsec VPN is

136
06:36.070 --> 06:36.640
functional

137
06:36.640 --> 06:39.080
and when it's coming online.

138
06:39.080 --> 06:42.760
But what if we get errors in this process?

139
06:42.760 --> 06:46.600
In the next video, let's take a look at some of the common errors that we can

140
06:46.600 --> 06:47.240
get

141
06:47.240 --> 06:48.720
as part of this process.

142
06:48.720 --> 06:56.940
[BLANK_AUDIO]