WEBVTT

1
00:00.000 --> 00:05.460
So my question for you is, did you identify what the problem is with the site-

2
00:05.460 --> 00:05.760
to-site

3
00:05.760 --> 00:09.360
route-based VPN between site 3 and site 4?

4
00:09.360 --> 00:10.360
I hope you did.

5
00:10.360 --> 00:13.880
And what I'd like to do right now is do a walkthrough by taking a look at the

6
00:13.880 --> 00:15.200
live interface

7
00:15.200 --> 00:18.990
and then together walking through and identifying what the problem is and then

8
00:18.990 --> 00:19.960
also after implementing

9
00:19.960 --> 00:24.320
a correction to verify that what we thought was wrong indeed was the problem.

10
00:24.320 --> 00:28.580
So to start off, what I'd recommend and we do is let's do a quick check here at

11
00:28.580 --> 00:28.680
the

12
00:28.680 --> 00:33.040
red VM as we try to ping the IP address of this purple VM.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

12
00:28.680 --> 00:33.040
red VM as we try to ping the IP address of this purple VM.

13
00:33.040 --> 00:36.910
Another option is we could also try to ping the IP address of the tier 0

14
00:36.910 --> 00:38.040
gateway interface

15
00:38.040 --> 00:39.760
that connects to this segment.

16
00:39.760 --> 00:45.160
So we could try to ping 10.44.0.1 and that way we wouldn't have to worry

17
00:45.160 --> 00:46.200
specifically

18
00:46.200 --> 00:49.160
about which IP address a client on the other side had.

19
00:49.160 --> 00:53.670
So for testing purposes, let's go ahead and test what they ping to this IP

20
00:53.670 --> 00:54.400
address as

21
00:54.400 --> 01:00.840
a known given the 10.44.0.1 and let's try that from the VM over here at site 3.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

21
00:54.400 --> 01:00.840
a known given the 10.44.0.1 and let's try that from the VM over here at site 3.

22
01:00.840 --> 01:06.860
So here is the site 3 VM and let's do a ping over to 10.44.0.1 and sure enough

23
01:06.860 --> 01:07.320
that is

24
01:07.320 --> 01:11.130
not working and it's going to leave that ping attempting in the background over

25
01:11.130 --> 01:11.720
and over

26
01:11.720 --> 01:15.460
again and that way when it does start working, those ping should automatically

27
01:15.460 --> 01:16.200
start working

28
01:16.200 --> 01:17.200
as well.

29
01:17.200 --> 01:20.350
And just to confirm what the active edge node is, we'll click on networking

30
01:20.350 --> 01:20.760
network

31
01:20.760 --> 01:26.330
topology here at site 3 and we'll go ahead and double click on the tier 0

32
01:26.330 --> 01:27.280
gateway and

33
01:27.280 --> 01:34.160
what we want to do is go to lab 3-1 and its management IP address is dot 36.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

33
01:27.280 --> 01:34.160
what we want to do is go to lab 3-1 and its management IP address is dot 36.

34
01:34.160 --> 01:38.050
So let's go to that edge node for a moment and just check basic connectivity

35
01:38.050 --> 01:38.240
over to

36
01:38.240 --> 01:39.240
24.1.2.40.

37
01:39.240 --> 01:41.200
All right.

38
01:41.200 --> 01:42.320
So here we are at edge 1.

39
01:42.320 --> 01:46.400
We'll do a get gateways and then we'll go into VRF for VRF 1.

40
01:46.400 --> 01:51.860
That's our services router and we'll do a ping over to 24.1.2.40 and sure

41
01:51.860 --> 01:52.480
enough, so

42
01:52.480 --> 01:57.080
that confirms that we have basic external connectivity on both gateways from

43
01:57.080 --> 01:57.880
the gateway

44
01:57.880 --> 02:02.080
0 at site 3 to the gateway 0 at site 4.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

44
01:57.880 --> 02:02.080
0 at site 3 to the gateway 0 at site 4.

45
02:02.080 --> 02:06.000
Also over here, let's do a get route and that'll show us our routing table and

46
02:06.000 --> 02:06.600
there's the

47
02:06.600 --> 02:11.240
default route and I don't see a route to the 10.44 subnets.

48
02:11.240 --> 02:16.110
So that's very likely at least one of our problems, the site 3 does not have a

49
02:16.110 --> 02:16.520
route

50
02:16.520 --> 02:22.680
that's using the next top of 103434 dot 44 to reach the 1044 networks.

51
02:22.680 --> 02:27.550
So back at the NSX manager under VPNs, if we look at our IP succession and

52
02:27.550 --> 02:28.720
expand site

53
02:28.720 --> 02:30.760
4, hmm, that says enable.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

53
02:28.720 --> 02:30.760
4, hmm, that says enable.

54
02:30.760 --> 02:33.240
Let's do a refresh and look at site 4.

55
02:33.240 --> 02:34.480
It says there's no problem.

56
02:34.480 --> 02:37.600
That's because the actual IPsec tunnel itself is happy, happy.

57
02:37.600 --> 02:40.320
It's up and running between site 3 and site 4.

58
02:40.320 --> 02:43.640
It's just isn't trying to use that path as it's forwarding traffic.

59
02:43.640 --> 02:46.390
Also another really handy tool in troubleshooting is this option right here,

60
02:46.390 --> 02:47.200
download config.

61
02:47.200 --> 02:51.400
Let's imagine you have two sites and you want to check out all the details and

62
02:51.400 --> 02:52.240
the endpoints,

63
02:52.240 --> 02:55.280
everything else and the protocols being used between the two sites.

64
02:55.280 --> 02:58.680
What you can do is download the config from both sites and then open it up in a

65
02:58.680 --> 02:59.280
text editor

66
02:59.280 --> 03:00.880
and go through them step by step.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

66
02:59.280 --> 03:00.880
and go through them step by step.

67
03:00.880 --> 03:03.960
So sometimes it's super helpful to have these side by side.

68
03:03.960 --> 03:07.710
Have one site in a document on the left hand side of your screen, have the

69
03:07.710 --> 03:08.520
other site in

70
03:08.520 --> 03:11.400
a document on the right hand side of the screen and just go through it step by

71
03:11.400 --> 03:11.800
step.

72
03:11.800 --> 03:15.950
So this is showing us the initial like tunnel information with the hashing and

73
03:15.950 --> 03:16.840
the encryption

74
03:16.840 --> 03:18.000
and so forth.

75
03:18.000 --> 03:21.950
It's also showing us for the IPsec tunnel and there's the encryption that we

76
03:21.950 --> 03:22.560
modified

77
03:22.560 --> 03:24.880
at the tail end of our set of videos.

78
03:24.880 --> 03:27.750
And so what we can do is just compare all these details with what's set up on

79
03:27.750 --> 03:28.320
the other

80
03:28.320 --> 03:29.320
site as well.

81
03:29.320 --> 03:32.160
However, because the tunnel is up, we can go ahead and dismiss that because the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

81
03:29.320 --> 03:32.160
However, because the tunnel is up, we can go ahead and dismiss that because the

82
03:32.160 --> 03:32.520
actual

83
03:32.520 --> 03:35.440
tunnel itself isn't having the problem, it's the route.

84
03:35.440 --> 03:37.640
So let's go back to our tier 0 gateway.

85
03:37.640 --> 03:39.160
We'll click on the three dots.

86
03:39.160 --> 03:43.240
We'll click on edit, let's go down to our routing and we have two routes there.

87
03:43.240 --> 03:47.420
Oh, we have one default route and we have a route for IPsec policy based tunnel

88
03:47.420 --> 03:47.960
to an

89
03:47.960 --> 03:53.240
external Cisco router, but we don't have the route to the 1044 subnet.

90
03:53.240 --> 03:57.880
So let's add that by clicking on add static route, we'll call this subnets at

91
03:57.880 --> 03:58.680
site four.

92
03:58.680 --> 04:02.560
We'll specify the 10 dot 44 address space for the 16 bit mass.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

92
03:58.680 --> 04:02.560
We'll specify the 10 dot 44 address space for the 16 bit mass.

93
04:02.560 --> 04:07.010
So 1044 anything and for the next hop, we'll click on set there and set the

94
04:07.010 --> 04:07.600
next hop to

95
04:07.600 --> 04:13.090
10 dot 34 dot 34 dot 44, which based on apology and how we set up these

96
04:13.090 --> 04:14.680
sessions is the IP

97
04:14.680 --> 04:19.040
address on the virtual tunnel interface that we're using over at site four.

98
04:19.040 --> 04:23.120
And then for the scope, I'm also going to limit the scope to our IPsec session.

99
04:23.120 --> 04:27.080
So I'll select that and then click on add and then click on apply.

100
04:27.080 --> 04:31.080
And then before I click on save, let me just take a peek here at our client.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

100
04:27.080 --> 04:31.080
And then before I click on save, let me just take a peek here at our client.

101
04:31.080 --> 04:33.840
So here is our little client still trying to do his pings.

102
04:33.840 --> 04:35.040
Let me do a control C.

103
04:35.040 --> 04:39.560
Yeah, sure enough, 581 packets that were sent, none received.

104
04:39.560 --> 04:40.960
So we'll start that ping again.

105
04:40.960 --> 04:44.640
They'll go over here and we'll click on save and close.

106
04:44.640 --> 04:48.480
And if that was the whole problem, those pings should now be working.

107
04:48.480 --> 04:49.800
So let's bring back the client.

108
04:49.800 --> 04:54.070
So here's our client and sure enough, those pings are now beginning to go

109
04:54.070 --> 04:54.840
through.

110
04:54.840 --> 04:56.640
So that was our issue at site three.

111
04:56.640 --> 04:58.720
We had a missing route.

112
04:58.720 --> 05:02.140
And as a result, our tier zero gateway was not trying to send the traffic that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

112
04:58.720 --> 05:02.140
And as a result, our tier zero gateway was not trying to send the traffic that

113
05:02.140 --> 05:02.760
was destined

114
05:02.760 --> 05:07.160
for 1044, anything, it wasn't trying to send that over the tunnel.

115
05:07.160 --> 05:11.000
And that's what was causing our route based IPsec site, site tunnel between

116
05:11.000 --> 05:11.640
site three

117
05:11.640 --> 05:16.690
and site four to fail was that although it was a route based VPN, we didn't

118
05:16.690 --> 05:17.320
have the

119
05:17.320 --> 05:19.280
correct route in place.

120
05:19.280 --> 05:22.720
And now that we do, if we go back to VPN and IPsec sessions and go back to our

121
05:22.720 --> 05:23.440
IPsec session

122
05:23.440 --> 05:27.970
to site four and we click on view statistics, we should now have packets that

123
05:27.970 --> 05:28.560
are going

124
05:28.560 --> 05:33.470
through and if that ping is still running, which it is, if we click on refresh
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

124
05:28.560 --> 05:33.470
through and if that ping is still running, which it is, if we click on refresh

125
05:33.470 --> 05:34.000
here,

126
05:34.000 --> 05:38.240
those counters should be increasing, which they are fantastic.

127
05:38.240 --> 05:41.450
So thanks for joining me in this set of videos and in the skill regarding

128
05:41.450 --> 05:42.320
configuring and

129
05:42.320 --> 05:48.480
verifying an IPsec route based VPN tunnel between two tier zero gateways in an

130
05:48.480 --> 05:49.760
NSX environment.

131
05:49.760 --> 05:53.380
And I look forward to seeing you my friend in another set of videos very, very

132
05:53.380 --> 05:53.920
soon.

133
05:53.920 --> 05:58.100
Until then, I hope this has been informative and I'd like to thank you for

134
05:58.100 --> 05:58.520
viewing.