WEBVTT

1
00:00.000 --> 00:03.680
So now that we have the IPsec tunnel up, it's time to verify that it really is

2
00:03.680 --> 00:04.400
doing what we

3
00:04.400 --> 00:08.640
wanted it to do and that is to protect all the traffic that's going out from

4
00:08.640 --> 00:10.160
this T0 gateway.

5
00:10.160 --> 00:15.360
If that traffic is coming from 1033-0 and going to 1080 to make sure that it's

6
00:15.360 --> 00:15.760
going

7
00:15.760 --> 00:19.600
over the IPsec tunnel, which gives it the protection. So again, if this was

8
00:19.600 --> 00:20.640
like the internet and

9
00:20.640 --> 00:23.300
that traffic is all being said over the internet, if we're encrypting

10
00:23.300 --> 00:23.840
everything,

11
00:23.840 --> 00:27.320
and eavesdroppers are stealing those packets or getting copies of those packets

12
00:27.320 --> 00:28.080
, because they

13
00:28.080 --> 00:31.480
are encrypted, they are meaning this as far as the contents and the payloads of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

13
00:28.080 --> 00:31.480
are encrypted, they are meaning this as far as the contents and the payloads of

14
00:31.480 --> 00:32.480
those packets,

15
00:32.480 --> 00:36.320
because the hackers cannot decrypt that traffic. The only two entities that can

16
00:36.320 --> 00:37.360
decrypt it are

17
00:37.360 --> 00:42.300
the T0 gateway and the Cisco router on the other end of that same IPsec tunnel.

18
00:42.300 --> 00:42.720
Let's go to this

19
00:42.720 --> 00:47.940
VM right here and start sending some traffic over to the IP address 1080.10. So

20
00:47.940 --> 00:48.880
here the vSphere

21
00:48.880 --> 00:53.060
client for the red portion of my lab, let's go to the networking tab, let's go

22
00:53.060 --> 00:54.000
to our red 3

23
00:54.000 --> 00:59.050
segment 33. And I've got two VMs there, one that's on a host number one, one's

24
00:59.050 --> 01:00.080
on host number two.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

24
00:59.050 --> 01:00.080
on host number two.

25
01:00.080 --> 01:04.740
Let's bring up red one. So we'll right click on red one, click on power and

26
01:04.740 --> 01:06.240
power it on. And while

27
01:06.240 --> 01:10.280
it's powering on, let's also bring up a remote console by right clicking, then

28
01:10.280 --> 01:10.800
from the menu

29
01:10.800 --> 01:15.210
clicking on open remote console. Now before we send any traffic from this

30
01:15.210 --> 01:16.000
little red VM,

31
01:16.000 --> 01:20.560
which is sitting right here, let's also go back to the NSX manager and just

32
01:20.560 --> 01:21.440
confirm what the

33
01:21.440 --> 01:26.240
current hit counts are for traffic over our IPsec tunnel. So back at the NSX

34
01:26.240 --> 01:27.120
manager, if we click on

35
01:27.120 --> 01:31.830
networking and then on the left under network services, we'll click on VPN. And
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

35
01:27.120 --> 01:31.830
networking and then on the left under network services, we'll click on VPN. And

36
01:31.830 --> 01:32.400
then to take a

37
01:32.400 --> 01:36.290
look at our IPsec session between our T0 gateway and our Cisco router, we'll

38
01:36.290 --> 01:37.280
click right here on

39
01:37.280 --> 01:41.830
the sub tab of IPsec sessions. And then from here, we'll go ahead and click on

40
01:41.830 --> 01:43.120
view statistics right

41
01:43.120 --> 01:46.290
there. So I'm still expecting all that to be zero because we haven't sent any

42
01:46.290 --> 01:47.680
traffic specifically

43
01:47.680 --> 01:52.400
from the 1033 zero network over to the 1080 network. And let's now change that

44
01:52.400 --> 01:53.440
by going to our red

45
01:53.440 --> 01:57.040
VM, which is right here, slowly make that a little bit bigger. And from this

46
01:57.040 --> 01:57.760
red VM, let's go

47
01:57.760 --> 02:02.060
ahead and do an I have config just to confirm its IP address. So I have config
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

47
01:57.760 --> 02:02.060
ahead and do an I have config just to confirm its IP address. So I have config

48
02:02.060 --> 02:03.040
ethernet zero,

49
02:03.040 --> 02:09.580
press enter, and it has the IP address of 1033 zero dot 151. So we did a ping

50
02:09.580 --> 02:11.680
over to the IP address

51
02:11.680 --> 02:17.900
of the router on that subnet of 10 dot 8 dot 0 dot 10, that traffic coming from

52
02:17.900 --> 02:19.200
1033 zero

53
02:19.200 --> 02:24.660
151 going to 10 8 0 10, that should match our policy that we have set up for

54
02:24.660 --> 02:26.000
our IPsec session.

55
02:26.000 --> 02:29.530
And the hit counts should increase for traffic going over the tunnel. So let's

56
02:29.530 --> 02:30.320
first of all verify
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

56
02:29.530 --> 02:30.320
first of all verify

57
02:30.320 --> 02:35.370
that it works. That's always a fun thing that it actually works. And now that

58
02:35.370 --> 02:36.320
it's actually running,

59
02:36.320 --> 02:41.000
let's go ahead back to the interface. And let's click on refresh right here. So

60
02:41.000 --> 02:41.600
we should see

61
02:41.600 --> 02:45.720
in packets in and packets out for the ping request and the ping responses, that

62
02:45.720 --> 02:46.720
should be incrementing.

63
02:46.720 --> 02:50.420
And it is. And so as that ping continues to happen to the background, if we

64
02:50.420 --> 02:52.160
click on refresh again,

65
02:52.160 --> 02:56.560
this hit count should increase. And that absolutely is the case. And if we went

66
02:56.560 --> 02:57.120
back over to the

67
02:57.120 --> 03:00.550
Cisco side just to confirm and hit the up arrow key and did the appropriate
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

67
02:57.120 --> 03:00.550
Cisco side just to confirm and hit the up arrow key and did the appropriate

68
03:00.550 --> 03:01.440
output here on the

69
03:01.440 --> 03:05.430
Cisco router, that's also going to indicate that packets are being encrypted

70
03:05.430 --> 03:06.240
and decrypted.

71
03:06.240 --> 03:09.980
And because that ping is still happening in the background, if we hit enter

72
03:09.980 --> 03:10.640
again and do that

73
03:10.640 --> 03:14.720
same command again, those are continuing to increase as well. Or if we hit the

74
03:14.720 --> 03:15.360
up arrow key a few

75
03:15.360 --> 03:19.480
times, you'll show crypto IPsec SA, those numbers are also reflected up here

76
03:19.480 --> 03:20.400
for encrypted and

77
03:20.400 --> 03:23.700
decrypted packets that are going over the tunnel. Again, this side would be

78
03:23.700 --> 03:24.880
from the perspective

79
03:24.880 --> 03:28.670
of the Cisco router. One other aspect that we kind of fun to do would be to

80
03:28.670 --> 03:29.920
capture that traffic

81
03:29.920 --> 03:33.390
and take a look at the payload. So even though there are pings, it could be SSH
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

81
03:29.920 --> 03:33.390
and take a look at the payload. So even though there are pings, it could be SSH

82
03:33.390 --> 03:34.160
, it could be anything

83
03:34.160 --> 03:38.290
else. If people are capturing that traffic as it goes over the tunnel, because

84
03:38.290 --> 03:39.200
of IPsec doing the

85
03:39.200 --> 03:43.750
encryption, the attacker or anybody who captures that traffic would not be able

86
03:43.750 --> 03:44.640
to identify what

87
03:44.640 --> 03:48.800
that payload is actually carrying. So to capture that traffic, let's go to the

88
03:48.800 --> 03:49.600
switch that is

89
03:49.600 --> 03:53.240
currently being used by the edge nodes, because behind the scenes where the VPN

90
03:53.240 --> 03:54.080
services is the

91
03:54.080 --> 03:58.910
edge nodes doing the work. So here's my switch that my edges are using for the

92
03:58.910 --> 03:59.840
transport network.

93
03:59.840 --> 04:03.360
And let me go ahead and edit the switch and set up mirroring. So with that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

93
03:59.840 --> 04:03.360
And let me go ahead and edit the switch and set up mirroring. So with that

94
04:03.360 --> 04:03.920
switch selected,

95
04:03.920 --> 04:07.750
we'll go to configure, go down to port mirroring, and click on new. And I'm

96
04:07.750 --> 04:08.240
going to choose

97
04:08.240 --> 04:12.650
encapsulated remote mirroring, click on next, it's going to use GRE to ship the

98
04:12.650 --> 04:13.840
traffic over.

99
04:13.840 --> 04:17.410
I'll click on next, because I'm not sure which edge node is being used. And

100
04:17.410 --> 04:18.000
then I capture the

101
04:18.000 --> 04:21.870
traffic from both of the edge nodes, click on next. And for the destination, I

102
04:21.870 --> 04:22.880
'll click on add,

103
04:22.880 --> 04:27.080
and I'm going to add the IP address of my management computer, which is 192.168

104
04:27.080 --> 04:28.320
.1.151,

105
04:28.320 --> 04:32.690
click on next, and click on finish. And now that it's here, it's disabled by
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

105
04:28.320 --> 04:32.690
click on next, and click on finish. And now that it's here, it's disabled by

106
04:32.690 --> 04:33.200
default,

107
04:33.200 --> 04:38.020
I'll edit it, and I'll set it to enabled and click on. Okay, so that ping is

108
04:38.020 --> 04:38.800
happening in the

109
04:38.800 --> 04:42.140
background. And now let me go ahead and run some software on my local

110
04:42.140 --> 04:43.360
management computer, so we

111
04:43.360 --> 04:47.270
can go ahead and collect that data. So to collect it, I'm going to use wire

112
04:47.270 --> 04:48.080
shark. And let me put a

113
04:48.080 --> 04:53.740
quick filter in place, IP protocol 47, which is GRE traffic. And that way only

114
04:53.740 --> 04:54.720
the GRE traffic

115
04:54.720 --> 04:58.720
is going to show up inside the capture. And I want to choose this interface

116
04:58.720 --> 04:59.440
right there.

117
04:59.440 --> 05:03.440
All right, and there it is. So now that it's run for a moment, I also want to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

117
04:59.440 --> 05:03.440
All right, and there it is. So now that it's run for a moment, I also want to

118
05:03.440 --> 05:04.160
confirm that my

119
05:04.160 --> 05:08.060
pings are still running, which they are fantastic. Let me go ahead and stop the

120
05:08.060 --> 05:09.120
capture. I'm also

121
05:09.120 --> 05:12.720
going to turn off the port mirroring. So I'm going to edit that session and say

122
05:12.720 --> 05:14.480
disabled and okay.

123
05:14.480 --> 05:17.280
And let's go ahead and take a look at our capture. So there's a ton of traffic

124
05:17.280 --> 05:17.680
here. In fact,

125
05:17.680 --> 05:21.600
there's over 17,000 packets. So let's go ahead in the display filter. I'm going

126
05:21.600 --> 05:22.560
to type in ESP.

127
05:22.560 --> 05:27.340
ESP is one of the protocols used at layer four for IPsec. It's protocol number

128
05:27.340 --> 05:27.840
50.

129
05:27.840 --> 05:32.400
So with this display filter in place, it's only showing us ESP traffic. So here
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

129
05:27.840 --> 05:32.400
So with this display filter in place, it's only showing us ESP traffic. So here

130
05:32.400 --> 05:33.120
in this one packet

131
05:33.120 --> 05:39.180
going from 780060. That's our T zero external address going to 780010, which is

132
05:39.180 --> 05:40.320
the router address.

133
05:40.320 --> 05:44.310
Let's take a closer look at the details for that packet. And here it is. So the

134
05:44.310 --> 05:45.280
first four entries

135
05:45.280 --> 05:49.170
is just the encapsulation of the distributed switch shipping this content over

136
05:49.170 --> 05:49.920
to my management

137
05:49.920 --> 05:54.580
computer. As far as what was captured on the wire, we have an ethernet header.

138
05:54.580 --> 05:55.040
And based on the

139
05:55.040 --> 05:58.550
Mac addresses, it was sourced from a VMware device based on the layer two

140
05:58.550 --> 06:00.080
address going to a Cisco
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

140
05:58.550 --> 06:00.080
address going to a Cisco

141
06:00.080 --> 06:03.830
device. And that's wire shark in the background, helping us with identifying

142
06:03.830 --> 06:05.360
based on the first six

143
06:05.360 --> 06:09.420
hex characters of the Mac address regarding who the vendors are. Then the next

144
06:09.420 --> 06:10.800
layer is the IP header,

145
06:10.800 --> 06:14.700
which shows us the source and destination for the IP traffic. And then inside

146
06:14.700 --> 06:15.360
the IP header,

147
06:15.360 --> 06:21.030
it specifies what the next protocol is. So instead of saying, Hey, it's ICMP or

148
06:21.030 --> 06:23.280
Hey, it's UDP or TCP,

149
06:23.280 --> 06:27.600
it's showing us that the next protocol is protocol 50, which is the number for

150
06:27.600 --> 06:28.480
ESP.

151
06:28.480 --> 06:33.240
And then we have the ESP payload right here. And it has the SPI, the security
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

151
06:28.480 --> 06:33.240
And then we have the ESP payload right here. And it has the SPI, the security

152
06:33.240 --> 06:34.400
parameter index.

153
06:34.400 --> 06:39.110
But the contents are all encrypted. But as far as the payload goes, anybody who

154
06:39.110 --> 06:40.480
captures this traffic

155
06:40.480 --> 06:46.240
doesn't know if it was an SSH session or a telnet session or HTTPS session. So

156
06:46.240 --> 06:46.960
for the payload,

157
06:46.960 --> 06:52.080
as part of ESP, all that content is encrypted. So if we close that, that story

158
06:52.080 --> 06:52.800
continues back

159
06:52.800 --> 06:56.600
and forth for all of those pings. So right here from the client, if we tried

160
06:56.600 --> 06:57.680
using an insecure

161
06:57.680 --> 07:00.960
protocol, for example, like telnet, and we tell that that router rests on that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

161
06:57.680 --> 07:00.960
protocol, for example, like telnet, and we tell that that router rests on that

162
07:00.960 --> 07:02.320
protected subnet of 10

163
07:02.320 --> 07:07.070
dot eight dot zero dot 10 and press enter, you'll notice that we are connected

164
07:07.070 --> 07:08.080
to that router.

165
07:08.080 --> 07:12.080
So we do it, for example, show IP interface brief, or if we did a show crypto

166
07:12.080 --> 07:13.600
map, we are connected,

167
07:13.600 --> 07:17.000
using a very insecure protocol like telnet to the IP address there on the

168
07:17.000 --> 07:17.840
router. And again,

169
07:17.840 --> 07:21.310
the benefit is as that traffic goes over the tunnel, the payload, even though

170
07:21.310 --> 07:22.240
it's telnet that the

171
07:22.240 --> 07:25.720
client is actually using, which is not safe, as that traffic goes over the

172
07:25.720 --> 07:27.280
tunnel, anybody eavesdropping

173
07:27.280 --> 07:31.020
over the tunnel is not going to have a clue about what the protocol is that's
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

173
07:27.280 --> 07:31.020
over the tunnel is not going to have a clue about what the protocol is that's

174
07:31.020 --> 07:31.920
been encrypted,

175
07:31.920 --> 07:36.640
because it just looks to the attacker or to the unauthorized eyes as an ESP

176
07:36.640 --> 07:37.440
payload,

177
07:37.440 --> 07:40.680
which once again has been encrypted by this t zero gateway before it shipped

178
07:40.680 --> 07:41.440
over the tunnel,

179
07:41.440 --> 07:45.040
and then decrypted here at the Cisco router. And because we are going between

180
07:45.040 --> 07:45.760
the two protected

181
07:45.760 --> 07:50.100
subnets, all the payload back and forth over that tunnel is protected as it

182
07:50.100 --> 07:51.120
goes over the transport

183
07:51.120 --> 07:54.880
network, which in our case is our VLAN 78 here in this lab.

184
07:54.880 --> 08:04.880
[BLANK_AUDIO]