WEBVTT

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


2
00:00.117 --> 00:02.700 align:middle line:90%
In this video, I'd like to share
with you some troubleshooting

3
00:02.700 --> 00:04.620 align:middle line:90%
methodologies that we
can apply when we're

4
00:04.620 --> 00:06.518 align:middle line:84%
troubleshooting IPsec VPNs.

5
00:06.518 --> 00:09.060 align:middle line:90%
And the first thing I'd like to
chat with you about regarding

6
00:09.060 --> 00:11.520 align:middle line:90%
troubleshooting why a
VPN may not be working

7
00:11.520 --> 00:14.070 align:middle line:84%
is one word, and that's routing.

8
00:14.070 --> 00:17.870 align:middle line:90%
In most cases, with our VPNs, we
have some type of policy that's

9
00:17.870 --> 00:19.342 align:middle line:84%
associated with an interface.

10
00:19.342 --> 00:21.300 align:middle line:90%
If there are legacy crypto
maps, the crypto map

11
00:21.300 --> 00:22.800 align:middle line:90%
would be applied
to an interface.

12
00:22.800 --> 00:25.380 align:middle line:90%
If it's a VTI, a Virtual
Tunnel Interface,

13
00:25.380 --> 00:28.350 align:middle line:90%
we'd have an IPsec profile
associated with that interface.

14
00:28.350 --> 00:31.650 align:middle line:90%
And either way, the key is,
when traffic crosses over
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

14
00:28.350 --> 00:31.650 align:middle line:90%
And either way, the key is,
when traffic crosses over

15
00:31.650 --> 00:33.660 align:middle line:90%
that interface,
it's at that moment

16
00:33.660 --> 00:36.077 align:middle line:90%
that the router decides, oh,
should I encrypt this or not?

17
00:36.077 --> 00:38.452 align:middle line:90%
And if the answer is yes, the
router's then going to say,

18
00:38.452 --> 00:40.890 align:middle line:90%
do I have an IKE phase 1 if
we're using IKE version 1?

19
00:40.890 --> 00:43.770 align:middle line:90%
Do I have an IKE phase 1 tunnel
between myself and the peer?

20
00:43.770 --> 00:45.605 align:middle line:90%
And if not, they
negotiate it and build it.

21
00:45.605 --> 00:46.980 align:middle line:90%
And then after
that's built, they

22
00:46.980 --> 00:49.410 align:middle line:90%
would then negotiate and
build the IKE phase 2 tunnel.

23
00:49.410 --> 00:51.420 align:middle line:90%
Again, that's if we're
using IKE version 1.

24
00:51.420 --> 00:54.000 align:middle line:90%
But it was all triggered
by having traffic that

25
00:54.000 --> 00:55.690 align:middle line:84%
was routed over that interface.

26
00:55.690 --> 00:58.490 align:middle line:90%
So the key takeaway is that if
this router receives a packet,

27
00:58.490 --> 01:00.240 align:middle line:90%
and it doesn't believe
for whatever reason
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

27
00:58.490 --> 01:00.240 align:middle line:90%
and it doesn't believe
for whatever reason

28
01:00.240 --> 01:02.615 align:middle line:90%
that that traffic needs to be
routed over this interface,

29
01:02.615 --> 01:06.480 align:middle line:90%
the whole initial IPsec policy
won't be triggered or brought

30
01:06.480 --> 01:08.595 align:middle line:84%
up due to a lack of routing.

31
01:08.595 --> 01:10.470 align:middle line:90%
So my coaching would
be, the very first thing

32
01:10.470 --> 01:13.380 align:middle line:90%
we'd want to look at is
routing, is the router believing

33
01:13.380 --> 01:16.290 align:middle line:90%
that it should forward the
traffic over the interface

34
01:16.290 --> 01:19.230 align:middle line:90%
where our crypto policy, in
whatever flavor we're using,

35
01:19.230 --> 01:20.340 align:middle line:84%
is applied.

36
01:20.340 --> 01:22.230 align:middle line:90%
And so here, if our
entering traffic

37
01:22.230 --> 01:25.200 align:middle line:90%
was supposed to be from 10.1.0
going to 10.2.0 from R1's

38
01:25.200 --> 01:28.500 align:middle line:90%
perspective, we could go
ahead and do a show IP route

39
01:28.500 --> 01:30.180 align:middle line:90%
and say, OK, dear
Mr. R1, if you've
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

39
01:28.500 --> 01:30.180 align:middle line:90%
and say, OK, dear
Mr. R1, if you've

40
01:30.180 --> 01:32.955 align:middle line:90%
got a packet from
10.1.0 going to 10.2.0,

41
01:32.955 --> 01:34.260 align:middle line:84%
what would you do with it?

42
01:34.260 --> 01:35.968 align:middle line:90%
And maybe there is a
default route that's

43
01:35.968 --> 01:37.260 align:middle line:84%
forcing it out this interface.

44
01:37.260 --> 01:38.668 align:middle line:84%
Or maybe there's a static route.

45
01:38.668 --> 01:40.710 align:middle line:90%
But if there's no route,
or if the route goes out

46
01:40.710 --> 01:43.420 align:middle line:90%
a different interface, and
the policy is applied here,

47
01:43.420 --> 01:45.420 align:middle line:90%
again, that'd be a miss,
and it wouldn't trigger

48
01:45.420 --> 01:47.070 align:middle line:84%
the whole IPsec process.

49
01:47.070 --> 01:48.570 align:middle line:90%
So from a routing
perspective, let's

50
01:48.570 --> 01:51.690 align:middle line:90%
take a look at R1 and its
routing table and ask ourselves

51
01:51.690 --> 01:53.430 align:middle line:90%
the question, if
traffic is coming

52
01:53.430 --> 01:57.010 align:middle line:90%
from 10.1.0 going to 10.2.0,
what will it do with it?

53
01:57.010 --> 02:00.240 align:middle line:90%
So here on R1, if we
did a show IP route
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

53
01:57.010 --> 02:00.240 align:middle line:90%
So here on R1, if we
did a show IP route

54
02:00.240 --> 02:02.100 align:middle line:90%
and looked at its routing
table, and then we

55
02:02.100 --> 02:03.642 align:middle line:90%
asked ourselves the
question, traffic

56
02:03.642 --> 02:06.330 align:middle line:84%
from 10.1.0 going to 10.2.0--

57
02:06.330 --> 02:08.590 align:middle line:90%
there's no explicit
match for 10.2 anything,

58
02:08.590 --> 02:10.720 align:middle line:90%
so it would use
the default route.

59
02:10.720 --> 02:14.160 align:middle line:90%
And that default route has
the next hop of 15.1.1.5.

60
02:14.160 --> 02:16.650 align:middle line:90%
And hopefully, to
reach 15.1.1.5,

61
02:16.650 --> 02:19.680 align:middle line:90%
we have the interface where the
actual cryptography is applied

62
02:19.680 --> 02:21.330 align:middle line:84%
which would trigger the IPsec.

63
02:21.330 --> 02:24.570 align:middle line:90%
So if our IPsec tunnel
was between R1 and R2,

64
02:24.570 --> 02:27.545 align:middle line:90%
and it was matching
on 10.1.0 to 10.2.0,

65
02:27.545 --> 02:30.308 align:middle line:90%
when R1 receives that packet, it
would make a routing decision.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

65
02:27.545 --> 02:30.308 align:middle line:90%
when R1 receives that packet, it
would make a routing decision.

66
02:30.308 --> 02:32.100 align:middle line:90%
And if this is the
interface that leads off

67
02:32.100 --> 02:34.680 align:middle line:90%
to 15.1.1.5, which
it is, that would

68
02:34.680 --> 02:36.503 align:middle line:90%
trigger the IPsec,
at which case,

69
02:36.503 --> 02:37.920 align:middle line:90%
if the tunnels
weren't already up,

70
02:37.920 --> 02:39.212 align:middle line:84%
it would negotiate the tunnels.

71
02:39.212 --> 02:40.290 align:middle line:84%
They'd build the tunnels.

72
02:40.290 --> 02:42.900 align:middle line:90%
And then that traffic could
be encrypted and shipped

73
02:42.900 --> 02:45.850 align:middle line:90%
through the tunnel
from R1 to R2.

74
02:45.850 --> 02:48.870 align:middle line:90%
So the internet would see
the IP addresses of 15.1.1.1

75
02:48.870 --> 02:50.075 align:middle line:84%
going to 25.2.2.2.

76
02:50.075 --> 02:52.590 align:middle line:90%
And the original payload,
including the original IP

77
02:52.590 --> 02:56.100 align:middle line:90%
header that was sourced, for
example, from 10.1.0.50--

78
02:56.100 --> 02:58.200 align:middle line:90%
that would all be
encapsulated and encrypted

79
02:58.200 --> 02:59.960 align:middle line:84%
and part of the payload.

80
02:59.960 --> 03:02.220 align:middle line:90%
So it'd be protected from
the eyes of the internet
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

80
02:59.960 --> 03:02.220 align:middle line:90%
So it'd be protected from
the eyes of the internet

81
03:02.220 --> 03:03.640 align:middle line:84%
or this public network.

82
03:03.640 --> 03:06.150 align:middle line:90%
So that's step number 1,
make sure we have routing

83
03:06.150 --> 03:08.280 align:middle line:90%
enabled correctly so
that the router wants

84
03:08.280 --> 03:10.810 align:middle line:90%
to forward through the interface
where the cryptography is

85
03:10.810 --> 03:11.310 align:middle line:84%
applied.

86
03:11.310 --> 03:14.910 align:middle line:90%
Second is, if we're going
to peer from R1 to R2,

87
03:14.910 --> 03:16.710 align:middle line:90%
we'd want to make
darn sure that we

88
03:16.710 --> 03:20.610 align:middle line:90%
have reachability between R1
and R2 on the transport network.

89
03:20.610 --> 03:22.180 align:middle line:84%
So let's verify that as well.

90
03:22.180 --> 03:26.550 align:middle line:90%
So if the peers are supposed
to be 15.1.1.1 and 25.2.2.2,

91
03:26.550 --> 03:28.590 align:middle line:90%
we'd want to look
at the routing table

92
03:28.590 --> 03:31.540 align:middle line:90%
and verify that we have
reachability between those two
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

92
03:28.590 --> 03:31.540 align:middle line:90%
and verify that we have
reachability between those two

93
03:31.540 --> 03:32.040 align:middle line:84%
endpoints.

94
03:32.040 --> 03:33.723 align:middle line:90%
And by default,
with IPsec, they're

95
03:33.723 --> 03:35.140 align:middle line:90%
going to negotiate
the [INAUDIBLE]

96
03:35.140 --> 03:39.900 align:middle line:90%
again for the IKE phase 1
tunnel with UDP port 500.

97
03:39.900 --> 03:42.150 align:middle line:90%
And for the actual IPsec
tunnel, unless we're

98
03:42.150 --> 03:44.370 align:middle line:90%
using NAT traversal,
it'll be using

99
03:44.370 --> 03:48.917 align:middle line:90%
ESP, which is protocol
number 50 at layer 4.

100
03:48.917 --> 03:51.000 align:middle line:90%
So if there's something
preventing those protocols

101
03:51.000 --> 03:53.430 align:middle line:90%
between the two endpoints,
the two endpoints of the VPN

102
03:53.430 --> 03:55.600 align:middle line:90%
tunnel, again, that
would cause a problem.

103
03:55.600 --> 03:57.390 align:middle line:90%
So routing-- make
sure it's working,

104
03:57.390 --> 03:59.015 align:middle line:90%
and then make sure
we have reachability

105
03:59.015 --> 04:01.182 align:middle line:90%
between the endpoints
of the VPN tunnel.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

105
03:59.015 --> 04:01.182 align:middle line:90%
between the endpoints
of the VPN tunnel.

106
04:01.182 --> 04:03.390 align:middle line:90%
So after we've verified
routing and also reachability

107
04:03.390 --> 04:04.765 align:middle line:90%
between the peers,
we'd also want

108
04:04.765 --> 04:07.250 align:middle line:90%
to verify that we have the
correct policy implemented.

109
04:07.250 --> 04:10.350 align:middle line:90%
And it depends on, are we
using version 1 or version 2?

110
04:10.350 --> 04:12.030 align:middle line:90%
And do we have
compatible IKE phase

111
04:12.030 --> 04:15.900 align:middle line:90%
1 policies for version 1 and
compatible IPsec policies?

112
04:15.900 --> 04:18.240 align:middle line:90%
And do we have the correct
passwords or authentication

113
04:18.240 --> 04:21.149 align:middle line:90%
in place so they can both
negotiate, authenticate,

114
04:21.149 --> 04:23.003 align:middle line:90%
and build all the tunnels
that they need to?

115
04:23.003 --> 04:24.420 align:middle line:90%
And a lot of that
configuration is

116
04:24.420 --> 04:26.970 align:middle line:90%
going to depend on how
we've implemented IPsec.

117
04:26.970 --> 04:29.190 align:middle line:90%
So we have other sets of
videos on implementing

118
04:29.190 --> 04:32.550 align:middle line:90%
site-to-site tunnels with crypto
maps, with tunnel interfaces.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

118
04:29.190 --> 04:32.550 align:middle line:90%
site-to-site tunnels with crypto
maps, with tunnel interfaces.

119
04:32.550 --> 04:35.580 align:middle line:90%
We also have some videos
on GETVPN and DMVPN.

120
04:35.580 --> 04:37.820 align:middle line:90%
So in the next video,
here's what I propose we do.

121
04:37.820 --> 04:40.240 align:middle line:90%
In the next video, let's take
a look at the same topology.

122
04:40.240 --> 04:41.740 align:middle line:90%
And I'll bring it
up here once again

123
04:41.740 --> 04:43.070 align:middle line:84%
so we can get a preview of it.

124
04:43.070 --> 04:45.000 align:middle line:90%
And let's start off with
the troubleshooting exercise

125
04:45.000 --> 04:46.980 align:middle line:90%
where we're going to
troubleshoot IKE version

126
04:46.980 --> 04:49.770 align:middle line:90%
1 and IKE phase 1
and identify, first

127
04:49.770 --> 04:52.380 align:middle line:90%
of all, why it's not
working between R1 and R2.

128
04:52.380 --> 04:53.970 align:middle line:90%
And then we'll
implement a solution.

129
04:53.970 --> 04:56.110 align:middle line:90%
And all that's coming up
in the very next video.

130
04:56.110 --> 04:58.180 align:middle line:90%
So I'll see you there
in just a moment.

131
04:58.180 --> 05:00.570 align:middle line:90%
Meanwhile, I hope this has
been informative for you.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

131
04:58.180 --> 05:00.570 align:middle line:90%
Meanwhile, I hope this has
been informative for you.

132
05:00.570 --> 05:03.740 align:middle line:90%
And I'd like to thank
you for viewing.