WEBVTT

1
00:00.000 --> 00:07.200
So now that we have verified the functionality of the underlay, now it's time

2
00:07.200 --> 00:08.000
to take a look

3
00:08.000 --> 00:10.920
at the IPsec VPN itself.

4
00:10.920 --> 00:17.130
And as we jump into this demonstration, we have to understand that the IPsec

5
00:17.130 --> 00:19.000
VPN to AWS

6
00:19.000 --> 00:24.150
is currently up and functioning as we jump in and start looking at various show

7
00:24.150 --> 00:24.840
commands

8
00:24.840 --> 00:30.800
and debug commands that we can use to verify the IPsec VPN.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

8
00:24.840 --> 00:30.800
and debug commands that we can use to verify the IPsec VPN.

9
00:30.800 --> 00:36.210
Now as we jump into debug commands, please keep in mind that these give you

10
00:36.210 --> 00:37.280
information

11
00:37.280 --> 00:41.700
in real time of what's happening on that device.

12
00:41.700 --> 00:45.800
And these are just outstanding troubleshooting tools.

13
00:45.800 --> 00:50.660
However, since they are displaying real time information, they actually can be

14
00:50.660 --> 00:51.400
quite taxing

15
00:51.400 --> 00:52.920
on the device.

16
00:52.920 --> 00:57.840
So you do want to be very careful with debug, don't start too many at the same

17
00:57.840 --> 00:58.480
time.

18
00:58.480 --> 01:03.400
Also there are some debug that can seriously detriment the performance of a
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

18
00:58.480 --> 01:03.400
Also there are some debug that can seriously detriment the performance of a

19
01:03.400 --> 01:04.200
device.

20
01:04.200 --> 01:08.230
So if at the debug you've never used before or you're not familiar with, I

21
01:08.230 --> 01:09.000
would encourage

22
01:09.000 --> 01:14.280
you to test it in a lab environment before you try debug in production.

23
01:14.280 --> 01:19.560
Also, it's never a bad idea to have a second session open to the device you're

24
01:19.560 --> 01:20.160
going to

25
01:20.160 --> 01:21.680
be debugging.

26
01:21.680 --> 01:27.960
That way you can do an undibug all in that other session, have it ready to go.

27
01:27.960 --> 01:31.800
And if your debug gets out of hand, you can just hit enter in the other session
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

27
01:27.960 --> 01:31.800
And if your debug gets out of hand, you can just hit enter in the other session

28
01:31.800 --> 01:32.320
and turn

29
01:32.320 --> 01:34.120
off all the debugging.

30
01:34.120 --> 01:39.010
The reason you would have to do that by the way is you can actually have tons

31
01:39.010 --> 01:39.840
of backlog

32
01:39.840 --> 01:42.280
in the window you're trying to work in.

33
01:42.280 --> 01:48.220
And even blindly just typing undibug all and hitting enter can get stuck behind

34
01:48.220 --> 01:48.920
buffers

35
01:48.920 --> 01:51.720
and get delayed being sent to that device.

36
01:51.720 --> 01:56.630
So if you can have a second session open so you can turn off debugging if

37
01:56.630 --> 01:57.400
something goes

38
01:57.400 --> 01:58.400
wrong.

39
01:58.400 --> 02:02.400
And of course never ever type debug all.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

39
01:58.400 --> 02:02.400
And of course never ever type debug all.

40
02:02.400 --> 02:07.080
A lot of our platforms don't even allow that anymore and almost all of them

41
02:07.080 --> 02:07.960
will make you

42
02:07.960 --> 02:11.080
verify if you do accidentally type that.

43
02:11.080 --> 02:15.250
But the last thing you want to do is turn on all debugging even in a lab

44
02:15.250 --> 02:16.400
environment.

45
02:16.400 --> 02:19.000
These can crash your devices.

46
02:19.000 --> 02:23.630
So please be careful with the bugs again, incredibly powerful troubleshooting

47
02:23.630 --> 02:24.200
tools,

48
02:24.200 --> 02:27.320
but we do have to be careful with them and use them wisely.

49
02:27.320 --> 02:32.430
So all of that said, let's jump into the command line on on prem R1 and get
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

49
02:27.320 --> 02:32.430
So all of that said, let's jump into the command line on on prem R1 and get

50
02:32.430 --> 02:33.160
started

51
02:33.160 --> 02:38.440
taking a look at our IPsec VPN.

52
02:38.440 --> 02:44.220
So remembering that our IPsec VPN is an interface just like any other, a good

53
02:44.220 --> 02:45.240
place to start

54
02:45.240 --> 02:50.520
with troubleshooting is always going to be with the show IP interface brief.

55
02:50.520 --> 02:55.470
And as we can see here, we currently have two tunnels, tunnel one and tunnel

56
02:55.470 --> 02:56.160
two that

57
02:56.160 --> 02:58.640
are both up up.

58
02:58.640 --> 03:00.880
And these are both connected to AWS.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

58
02:58.640 --> 03:00.880
And these are both connected to AWS.

59
03:00.880 --> 03:04.600
Now we're not going to be looking at the AWS side right now.

60
03:04.600 --> 03:07.320
We're going to look at that in the next skill.

61
03:07.320 --> 03:11.200
But for right now, since we see that they're up up, clearly we know the AWS

62
03:11.200 --> 03:12.320
side is configured

63
03:12.320 --> 03:13.440
properly.

64
03:13.440 --> 03:18.100
We can of course also verify traffic over these tunnels with the methods that

65
03:18.100 --> 03:18.920
we saw in our

66
03:18.920 --> 03:20.720
previous videos.

67
03:20.720 --> 03:29.710
We could say, for example, ping the 169.254.166 for tunnel one and the way AWS

68
03:29.710 --> 03:31.480
sets up its addresses,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

68
03:29.710 --> 03:31.480
sets up its addresses,

69
03:31.480 --> 03:36.160
it's always going to be one address lower than the address they give us to use.

70
03:36.160 --> 03:40.890
So here we can see that this has transported over the tunnel or at least so it

71
03:40.890 --> 03:41.560
would seem

72
03:41.560 --> 03:46.280
we can see here by the average round trip time of 44 milliseconds that it

73
03:46.280 --> 03:47.440
probably wasn't

74
03:47.440 --> 03:48.440
local.

75
03:48.440 --> 03:52.760
Because if we pinged the local side of this, it would of course still work.

76
03:52.760 --> 03:56.850
But notice the round trip times are just a touch faster since they're never

77
03:56.850 --> 03:57.720
even actually

78
03:57.720 --> 03:59.280
leaving this router.

79
03:59.280 --> 04:02.880
So this is a pretty good indicator that our traffic's going over the tunnel.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

79
03:59.280 --> 04:02.880
So this is a pretty good indicator that our traffic's going over the tunnel.

80
04:02.880 --> 04:06.480
Of course, we have other ways to tell as well.

81
04:06.480 --> 04:10.680
So that said, let's take a look at some of our show crypto commands.

82
04:10.680 --> 04:14.080
The first one we'll look at is going to be for ICICAMP.

83
04:14.080 --> 04:17.480
So it's show crypto ICICAMP SA.

84
04:17.480 --> 04:21.340
Now in this case, we're not going to have any because this would be if we were

85
04:21.340 --> 04:21.740
using

86
04:21.740 --> 04:24.800
Ike version one, which we're not using.

87
04:24.800 --> 04:27.080
We're using Ike version two.

88
04:27.080 --> 04:34.360
So for our example, we instead want to change this to show crypto, Ike V2 SA.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

88
04:27.080 --> 04:34.360
So for our example, we instead want to change this to show crypto, Ike V2 SA.

89
04:34.360 --> 04:40.680
And if we do this, we now see that we have two different Ike V2 SA's.

90
04:40.680 --> 04:42.800
One is for tunnel ID one.

91
04:42.800 --> 04:45.240
The other one is for tunnel ID two.

92
04:45.240 --> 04:48.000
We can see here the local information.

93
04:48.000 --> 04:51.950
We also see the remote information so we can see the address we're connecting

94
04:51.950 --> 04:52.400
to on the

95
04:52.400 --> 04:54.240
other side.

96
04:54.240 --> 05:00.760
Also note that both of these are connecting on port 4500.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

96
04:54.240 --> 05:00.760
Also note that both of these are connecting on port 4500.

97
05:00.760 --> 05:05.670
This is a good indicator when we're talking about Ike that this is doing NAT

98
05:05.670 --> 05:06.640
traversal,

99
05:06.640 --> 05:09.160
which in this case, it most certainly is.

100
05:09.160 --> 05:13.480
These are going through a NAT device here at my local location.

101
05:13.480 --> 05:18.560
If there was no NAT traversal, this would simply be port 500.

102
05:18.560 --> 05:23.480
Of course, other things we can see here, the status is of course ready.

103
05:23.480 --> 05:28.580
Anything other than ready indicates that it's not actually functioning properly

104
05:28.580 --> 05:28.640
.

105
05:28.640 --> 05:33.520
And of course, the cause of it not working properly would most likely be any of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

105
05:28.640 --> 05:33.520
And of course, the cause of it not working properly would most likely be any of

106
05:33.520 --> 05:34.000
these

107
05:34.000 --> 05:38.240
settings down here below where we can see the encryption being used.

108
05:38.240 --> 05:45.760
In this case, it's a yes GCM specifically with a key size of 256 bits.

109
05:45.760 --> 05:49.120
We see our PRF is set to SHA 512.

110
05:49.120 --> 05:51.760
The hash is currently set to none.

111
05:51.760 --> 05:54.920
Our Diffie-Hellman group is set to group 20.

112
05:54.920 --> 05:58.200
It's using pre-shared key for authentication.

113
05:58.200 --> 06:04.200
And we see that our key lifetime and active time is listed here as well.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

113
05:58.200 --> 06:04.200
And we see that our key lifetime and active time is listed here as well.

114
06:04.200 --> 06:09.360
We also see the local SPI and the remote SPI listed here for reference as well.

115
06:09.360 --> 06:15.080
Again, the most common reason for an IPsec VPN not to come up would of course

116
06:15.080 --> 06:15.920
be either

117
06:15.920 --> 06:20.760
incorrect neighbors being listed or incorrect encryption parameters.

118
06:20.760 --> 06:26.080
Now, this of course is just looking at phase one, which is our Ike exchange.

119
06:26.080 --> 06:30.320
There's also going to be a security association for IPsec.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

119
06:26.080 --> 06:30.320
There's also going to be a security association for IPsec.

120
06:30.320 --> 06:34.320
So there's also of course a show crypto IPsec asset.

121
06:34.320 --> 06:39.740
Now this one is going to show us a lot more information from my standpoint when

122
06:39.740 --> 06:41.720
I'm troubleshooting.

123
06:41.720 --> 06:46.680
If the tunnel is not coming up, the first one I'm going to look at is the show

124
06:46.680 --> 06:47.200
crypto

125
06:47.200 --> 06:54.760
IP2SA because if I'm not getting a night version 2SA, then of course the IPsec

126
06:54.760 --> 06:55.240
SA is

127
06:55.240 --> 06:57.200
not going to be there either.

128
06:57.200 --> 06:59.640
So phase one has to complete.

129
06:59.640 --> 07:03.190
And if this doesn't complete and our status is not ready, then there's probably
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

129
06:59.640 --> 07:03.190
And if this doesn't complete and our status is not ready, then there's probably

130
07:03.190 --> 07:03.600
not too

131
07:03.600 --> 07:08.680
much of a point in looking at the show crypto IPsecSA except that it also will

132
07:08.680 --> 07:09.360
show you

133
07:09.360 --> 07:13.400
some parameters even though it's not actually working.

134
07:13.400 --> 07:17.020
But if we go ahead and take a look at this command, in this case, it's showing

135
07:17.020 --> 07:17.600
us tunnel

136
07:17.600 --> 07:18.680
two first.

137
07:18.680 --> 07:23.440
Now, remember, we actually did our ping over tunnel one.

138
07:23.440 --> 07:27.200
So let's actually look at the tunnel one parameters instead just because that

139
07:27.200 --> 07:27.920
has already

140
07:27.920 --> 07:29.680
seen traffic.

141
07:29.680 --> 07:34.030
Notice that on this particular tunnel, literally zero traffic has gone over
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

141
07:29.680 --> 07:34.030
Notice that on this particular tunnel, literally zero traffic has gone over

142
07:34.030 --> 07:35.240
this tunnel because

143
07:35.240 --> 07:40.730
we see here both the encapsulated and encrypted and the non compressed and the

144
07:40.730 --> 07:41.520
if we look

145
07:41.520 --> 07:44.520
at all of these packet fields, they're all zeros.

146
07:44.520 --> 07:49.120
So let's get under tunnel one and we'll look here at tunnel one instead.

147
07:49.120 --> 07:55.140
Now what we see here is that five packets have actually been not only encaps

148
07:55.140 --> 07:55.920
ulated and

149
07:55.920 --> 08:02.240
decapsulated but also encrypted and decrypted and digested and verified.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

149
07:55.920 --> 08:02.240
decapsulated but also encrypted and decrypted and digested and verified.

150
08:02.240 --> 08:07.220
So that is the ping that we just did a few moments ago where we sent five pings

151
08:07.220 --> 08:07.840
across

152
08:07.840 --> 08:09.440
this tunnel.

153
08:09.440 --> 08:13.800
So that's a really good indicator, of course, that the tunnel is functional.

154
08:13.800 --> 08:18.640
But just to go a little bit further up here, we can also, of course, see that

155
08:18.640 --> 08:19.280
the tunnel

156
08:19.280 --> 08:25.520
head on this side is the local address of 204 dot 186 dot 19 dot 10.

157
08:25.520 --> 08:27.800
That's our egress interface.

158
08:27.800 --> 08:31.360
We see that it is currently not functioning for a VRF in particular.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

158
08:27.800 --> 08:31.360
We see that it is currently not functioning for a VRF in particular.

159
08:31.360 --> 08:34.320
It's just working in the global routing table.

160
08:34.320 --> 08:39.000
We can also see for the local and the remote ident that we're actually encrypt

161
08:39.000 --> 08:39.520
ing all

162
08:39.520 --> 08:41.200
of the traffic.

163
08:41.200 --> 08:46.180
One of the advantages of doing a VTI, which is a virtual tunnel interface, is

164
08:46.180 --> 08:46.760
we don't

165
08:46.760 --> 08:53.440
have to use things like access lists to define interesting traffic.

166
08:53.440 --> 08:57.590
Once again, we see any packets that have been encapsulated, decapsulated,

167
08:57.590 --> 08:58.720
encrypted,

168
08:58.720 --> 09:03.920
decrypted, compressed or not compressed, not decompressed and so on.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

168
08:58.720 --> 09:03.920
decrypted, compressed or not compressed, not decompressed and so on.

169
09:03.920 --> 09:06.240
We see any send and receive errors.

170
09:06.240 --> 09:09.600
Always a good number to keep an eye on when we're troubleshooting things.

171
09:09.600 --> 09:14.510
Now, of course, on a production network, getting a small percentage of send and

172
09:14.510 --> 09:16.000
receive errors

173
09:16.000 --> 09:19.080
isn't going to be something to worry a whole lot about.

174
09:19.080 --> 09:26.900
However, if you're getting 5,000 packets through and 50 of them have errors,

175
09:26.900 --> 09:27.480
well, that's

176
09:27.480 --> 09:30.360
probably something you want to do some troubleshooting with.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

176
09:27.480 --> 09:30.360
probably something you want to do some troubleshooting with.

177
09:30.360 --> 09:36.740
If it's 5 million packets and 5 have had errors, probably not nearly as much of

178
09:36.740 --> 09:37.440
a concern.

179
09:37.440 --> 09:42.080
See, you really have to look at the ratio or the percentage of how many packets

180
09:42.080 --> 09:42.200
are

181
09:42.200 --> 09:43.200
having errors.

182
09:43.200 --> 09:47.280
Now, if we look a little bit further down here, we again see the two endpoints

183
09:47.280 --> 09:47.720
being

184
09:47.720 --> 09:48.800
listed.

185
09:48.800 --> 09:52.010
But something that might be a little bit more interesting here is to look at

186
09:52.010 --> 09:54.360
these MTUs.

187
09:54.360 --> 09:58.530
Because if you're trying to send traffic that cannot be fragmented down this

188
09:58.530 --> 09:59.320
tunnel, it would

189
09:59.320 --> 10:02.640
be important to know what the tunnel MTU is.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

189
09:59.320 --> 10:02.640
be important to know what the tunnel MTU is.

190
10:02.640 --> 10:07.520
The rest of this information here going further down is good information to

191
10:07.520 --> 10:08.120
have.

192
10:08.120 --> 10:11.260
But again, we're going to be getting into some really deep troubleshooting to

193
10:11.260 --> 10:11.840
need any

194
10:11.840 --> 10:15.080
of this information such as sibling flags.

195
10:15.080 --> 10:18.880
You're probably going to be pretty deep in troubleshooting at that point.

196
10:18.880 --> 10:22.520
And you'll want to look up what some of this information means.

197
10:22.520 --> 10:27.690
So next up, let's take a look at some useful debug commands so we can see what

198
10:27.690 --> 10:28.360
's going

199
10:28.360 --> 10:31.000
on when the tunnel is trying to come online.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

199
10:28.360 --> 10:31.000
on when the tunnel is trying to come online.

200
10:31.000 --> 10:40.000
[BLANK_AUDIO]