WEBVTT

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


2
00:02.235 --> 00:03.610 align:middle line:90%
In the previous
couple of videos,

3
00:03.610 --> 00:05.902 align:middle line:90%
we configured the key server
and then the group members

4
00:05.902 --> 00:07.277 align:middle line:90%
and now, it's time
to take a look

5
00:07.277 --> 00:09.190 align:middle line:90%
and verify that they
are working and they're

6
00:09.190 --> 00:10.610 align:middle line:84%
working as expected.

7
00:10.610 --> 00:13.150 align:middle line:90%
So speaking of expected,
what do we expect?

8
00:13.150 --> 00:17.080 align:middle line:90%
Well, the traffic policy
was that traffic from the 10

9
00:17.080 --> 00:19.930 align:middle line:90%
networks from 10 and two
10 should be encrypted,

10
00:19.930 --> 00:21.880 align:middle line:90%
and the crypto amounts
are being applied

11
00:21.880 --> 00:24.140 align:middle line:90%
on these egress
interfaces right here.

12
00:24.140 --> 00:27.370 align:middle line:90%
So if we-- in these
addresses on the inside,

13
00:27.370 --> 00:30.010 align:middle line:90%
I've got R2 at dot
two, and R1 at dot one,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

13
00:27.370 --> 00:30.010 align:middle line:90%
I've got R2 at dot
two, and R1 at dot one,

14
00:30.010 --> 00:33.260 align:middle line:90%
and R3 at dot three, so
we can generate traffic.

15
00:33.260 --> 00:35.140 align:middle line:90%
So as we send
traffic-- if we did

16
00:35.140 --> 00:38.350 align:middle line:90%
a ping, if we sourced
it from 10.2.0.2

17
00:38.350 --> 00:42.730 align:middle line:90%
and we destined to 10.1.0.1 or
10.3.0.3, what should happen

18
00:42.730 --> 00:47.170 align:middle line:90%
is, it would match the crypto
ACL, as part of our policy,

19
00:47.170 --> 00:50.380 align:middle line:90%
the packet would be encrypted
there being ESP header applied

20
00:50.380 --> 00:52.720 align:middle line:90%
and then outside of
that, the actual IP

21
00:52.720 --> 00:54.460 align:middle line:90%
header used for the
transport network

22
00:54.460 --> 00:55.700 align:middle line:84%
would be the same addresses.

23
00:55.700 --> 00:58.390 align:middle line:90%
So on the transport network,
it would look like a packet

24
00:58.390 --> 01:02.620 align:middle line:90%
from 10.2.0.2 to
10.1.0.1 and then
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

24
00:58.390 --> 01:02.620 align:middle line:90%
from 10.2.0.2 to
10.1.0.1 and then

25
01:02.620 --> 01:05.230 align:middle line:90%
following that, the
next protocol at layer 4

26
01:05.230 --> 01:07.270 align:middle line:90%
would be ESP and then
behind that would

27
01:07.270 --> 01:10.070 align:middle line:90%
be the mostly encrypted payload
that's probably the ESP header.

28
01:10.070 --> 01:11.520 align:middle line:90%
There are some details
that can be determined

29
01:11.520 --> 01:13.180 align:middle line:90%
but the bulk of the
payload is going

30
01:13.180 --> 01:14.830 align:middle line:90%
to be encrypted
with IPsec, that's

31
01:14.830 --> 01:17.270 align:middle line:84%
what we expect to have happen.

32
01:17.270 --> 01:20.065 align:middle line:90%
So let's go to the
CLI and take a look.

33
01:20.065 --> 01:21.940 align:middle line:90%
So just to make sure
it's not too much change

34
01:21.940 --> 01:25.010 align:middle line:90%
since our last deployment,
let's do on the key server--

35
01:25.010 --> 01:31.450 align:middle line:90%
show crypto gdoi, and we could
just do a-- show crypto gdoi,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

35
01:25.010 --> 01:31.450 align:middle line:90%
show crypto gdoi, and we could
just do a-- show crypto gdoi,

36
01:31.450 --> 01:33.432 align:middle line:90%
but we can also tap on
key server, awesome.

37
01:33.432 --> 01:35.140 align:middle line:90%
Those are going to
show us our key server

38
01:35.140 --> 01:38.290 align:middle line:90%
information and group
members is three, fantastic.

39
01:38.290 --> 01:41.170 align:middle line:90%
So looks like everything is
accounted for, and if we go

40
01:41.170 --> 01:44.980 align:middle line:90%
to R1, lets do a-- show
crypto isakmp, and do--

41
01:44.980 --> 01:46.420 align:middle line:84%
SA detail.

42
01:46.420 --> 01:50.080 align:middle line:90%
Now the crypto ISAKMP
SA, that's the connection

43
01:50.080 --> 01:53.650 align:middle line:90%
that we used to build the secure
tunnel up to the key server.

44
01:53.650 --> 01:55.180 align:middle line:90%
So after this
times out, we don't

45
01:55.180 --> 01:56.980 align:middle line:84%
have to keep this tunnel alive.

46
01:56.980 --> 01:58.510 align:middle line:90%
It was just initially
used, there's

47
01:58.510 --> 02:00.855 align:middle line:84%
a default life of like 24 hours.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

47
01:58.510 --> 02:00.855 align:middle line:84%
a default life of like 24 hours.

48
02:00.855 --> 02:02.230 align:middle line:90%
But there's the
[INAUDIBLE] phase

49
02:02.230 --> 02:04.540 align:middle line:90%
one policy detail
that we used as we

50
02:04.540 --> 02:07.550 align:middle line:90%
built that initial connection
up to the key server.

51
02:07.550 --> 02:09.400 align:middle line:90%
Now as we get our
policy pushed to us,

52
02:09.400 --> 02:13.835 align:middle line:90%
if we do a show crypto
ipsec SA and press enter,

53
02:13.835 --> 02:15.960 align:middle line:90%
so this is the security
association they got pushed

54
02:15.960 --> 02:17.830 align:middle line:90%
to us by the key server
and basically, it

55
02:17.830 --> 02:20.650 align:middle line:90%
says traffic that's
from 10 and going to 10,

56
02:20.650 --> 02:22.250 align:middle line:84%
go ahead and encrypt it.

57
02:22.250 --> 02:25.090 align:middle line:90%
So currently, we look at
packets encrypted and decrypted.

58
02:25.090 --> 02:27.400 align:middle line:90%
We've got nothing and
that's because we haven't

59
02:27.400 --> 02:29.240 align:middle line:84%
had any engine traffic yet.

60
02:29.240 --> 02:32.770 align:middle line:90%
So let's go and generate some,
we're on our R1 list to a ping,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

60
02:29.240 --> 02:32.770 align:middle line:90%
So let's go and generate some,
we're on our R1 list to a ping,

61
02:32.770 --> 02:36.850 align:middle line:90%
to 10.2.0.2 but in
order to make this work

62
02:36.850 --> 02:40.090 align:middle line:90%
and match this crypto ACL,
they've got pushed to us,

63
02:40.090 --> 02:42.650 align:middle line:90%
we would need to source it
from the 10 network as well.

64
02:42.650 --> 02:48.100 align:middle line:90%
So we would say source 10.1.0.1
and that flew, look at that.

65
02:48.100 --> 02:51.200 align:middle line:90%
That happened pretty darn quick,
let's do a up arrow key couple

66
02:51.200 --> 02:53.990 align:middle line:90%
of times, they'll show
crypto IPsec sa again,

67
02:53.990 --> 02:55.990 align:middle line:90%
so now, we have five
packets that were encrypted

68
02:55.990 --> 02:58.150 align:middle line:90%
and 5 packets that
were decrypted

69
02:58.150 --> 03:01.570 align:middle line:90%
using the policy that was
pushed down from the key server.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

69
02:58.150 --> 03:01.570 align:middle line:90%
using the policy that was
pushed down from the key server.

70
03:01.570 --> 03:03.760 align:middle line:90%
So and to see the details
of that policy we do,

71
03:03.760 --> 03:09.020 align:middle line:90%
show crypto, let's do a
gdoi and press Enter there.

72
03:09.020 --> 03:11.770 align:middle line:90%
So here's the information
from show crypto gdoi,

73
03:11.770 --> 03:13.750 align:middle line:90%
there's a lot of
data here, 848 is

74
03:13.750 --> 03:16.090 align:middle line:90%
UDB Port that we're
using to communicate

75
03:16.090 --> 03:18.310 align:middle line:90%
with the key server,
there is the IP

76
03:18.310 --> 03:19.990 align:middle line:84%
address of our key server.

77
03:19.990 --> 03:22.270 align:middle line:90%
As we scroll down,
here is the ACL

78
03:22.270 --> 03:24.490 align:middle line:90%
that we got downloaded
from the key server which

79
03:24.490 --> 03:28.310 align:middle line:90%
bases as traffic from 10 going
to 10, anything is a match,

80
03:28.310 --> 03:31.210 align:middle line:90%
encrypt it, or if it's
coming in, decrypt it.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

80
03:28.310 --> 03:31.210 align:middle line:90%
encrypt it, or if it's
coming in, decrypt it.

81
03:31.210 --> 03:32.948 align:middle line:90%
And want to deny
everything else,

82
03:32.948 --> 03:34.990 align:middle line:90%
and we want to deny
everything else, which means,

83
03:34.990 --> 03:38.320 align:middle line:90%
don't encrypt anything else
besides traffic from 10 to 10.

84
03:38.320 --> 03:40.970 align:middle line:90%
Regarding the KEK policy,
the key encryption key,

85
03:40.970 --> 03:43.360 align:middle line:90%
the Rekey is going to
be unicast and then

86
03:43.360 --> 03:46.480 align:middle line:90%
we have information about the
traffic encryption key, which

87
03:46.480 --> 03:48.100 align:middle line:90%
is based on the
transforms, which

88
03:48.100 --> 03:49.600 align:middle line:90%
were configured
on the key server

89
03:49.600 --> 03:50.965 align:middle line:84%
and pushed down to this router.

90
03:50.965 --> 03:52.840 align:middle line:90%
And what I thought would
be really fun to do,

91
03:52.840 --> 03:54.160 align:middle line:84%
so heck, let's do it, right?

92
03:54.160 --> 03:56.440 align:middle line:90%
Is take a look at a packet
capture, actually just do

93
03:56.440 --> 03:58.780 align:middle line:90%
a packet capture of
traffic before it

94
03:58.780 --> 04:01.640 align:middle line:90%
hits the router and then
after during the encryption,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

94
03:58.780 --> 04:01.640 align:middle line:90%
hits the router and then
after during the encryption,

95
04:01.640 --> 04:04.240 align:middle line:90%
and just take a look
at before and after,

96
04:04.240 --> 04:06.938 align:middle line:90%
and that will confirm the IP
header preservation and also

97
04:06.938 --> 04:08.980 align:middle line:90%
the fact that it's being
encapsulated with an ESP

98
04:08.980 --> 04:11.380 align:middle line:90%
header, and that the
payload is encrypted.

99
04:11.380 --> 04:13.240 align:middle line:90%
So to pull this off,
to capture the traffic

100
04:13.240 --> 04:16.209 align:middle line:90%
before it goes through
the crypto map here on R2,

101
04:16.209 --> 04:18.579 align:middle line:90%
let's use the help of a
little device here .50

102
04:18.579 --> 04:20.120 align:middle line:84%
of a little Linux box.

103
04:20.120 --> 04:21.670 align:middle line:90%
And what we can do
is, we can have--

104
04:21.670 --> 04:23.590 align:middle line:90%
and he's got a default
gateway pointing here,

105
04:23.590 --> 04:27.250 align:middle line:90%
we can go from 10.2.0.50 this
device and let's go ahead

106
04:27.250 --> 04:29.860 align:middle line:90%
and send some traffic up to
and in fact, let's do this,

107
04:29.860 --> 04:34.720 align:middle line:90%
I've got another device
up here at 10.1.0.50,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

107
04:29.860 --> 04:34.720 align:middle line:90%
I've got another device
up here at 10.1.0.50,

108
04:34.720 --> 04:35.970 align:middle line:84%
and it's other than Linux box.

109
04:35.970 --> 04:38.095 align:middle line:90%
And what we are going to
do is, we can send traffic

110
04:38.095 --> 04:38.960 align:middle line:84%
back and forth.

111
04:38.960 --> 04:41.260 align:middle line:90%
And we'll capture
traffic here before it

112
04:41.260 --> 04:43.720 align:middle line:90%
goes through the crypto
map and becomes encrypted

113
04:43.720 --> 04:46.000 align:middle line:90%
and then we'll see the
traffic here as we capture--

114
04:46.000 --> 04:48.430 align:middle line:90%
there and see that it's the
same source in this station IP

115
04:48.430 --> 04:51.010 align:middle line:90%
addresses, but we have
an ESP header, now

116
04:51.010 --> 04:53.283 align:middle line:90%
and then the payload
after that is encrypted.

117
04:53.283 --> 04:55.450 align:middle line:90%
So here on this device,
let's verify its IP address.

118
04:55.450 --> 04:59.890 align:middle line:90%
This is at site 2 with a 10.2
network with an-- ip addr,

119
04:59.890 --> 05:04.440 align:middle line:90%
and for it's ethernet
0 interface, 10.2.0.50.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

119
04:59.890 --> 05:04.440 align:middle line:90%
and for it's ethernet
0 interface, 10.2.0.50.

120
05:04.440 --> 05:07.410 align:middle line:90%
If we do a route
and press Enter,

121
05:07.410 --> 05:10.990 align:middle line:90%
its default gateways 10.2.0.2
which is R2, fantastic.

122
05:10.990 --> 05:17.730 align:middle line:90%
Let's do a ping to 10.1
up at site 1, 10.1.0.50,

123
05:17.730 --> 05:22.020 align:middle line:90%
and let's also do
a dash s for size,

124
05:22.020 --> 05:25.650 align:middle line:90%
and let's send 1,000 as far
as the size and that way,

125
05:25.650 --> 05:27.760 align:middle line:90%
it'd be easier to pick
up in the packet capture

126
05:27.760 --> 05:30.780 align:middle line:90%
as we look at the traffic that's
been encrypted because we won't
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

126
05:27.760 --> 05:30.780 align:middle line:90%
as we look at the traffic that's
been encrypted because we won't

127
05:30.780 --> 05:32.748 align:middle line:90%
be able to longer
see the payload

128
05:32.748 --> 05:33.790 align:middle line:84%
to see what was in there.

129
05:33.790 --> 05:37.260 align:middle line:90%
So we'll do that, and
let that go for a few,

130
05:37.260 --> 05:40.180 align:middle line:90%
let me do a Control C, let's
also open up a browser.

131
05:40.180 --> 05:42.400 align:middle line:90%
We'll send some
additional traffic over.

132
05:42.400 --> 05:45.623 align:middle line:90%
So in the browser,
we'll get a 10.1.0.50,

133
05:45.623 --> 05:47.790 align:middle line:90%
and that seems to work,
I'll hit refresh a few times

134
05:47.790 --> 05:49.573 align:middle line:90%
to generate some
additional traffic,

135
05:49.573 --> 05:51.240 align:middle line:90%
and now we've sent a
nice healthy amount

136
05:51.240 --> 05:52.932 align:middle line:84%
of data over the network.

137
05:52.932 --> 05:54.640 align:middle line:90%
Let's take a look at
the packet captures.

138
05:54.640 --> 05:56.015 align:middle line:90%
All right, so this
is the traffic

139
05:56.015 --> 05:58.380 align:middle line:90%
it captured before
it hit R2, this

140
05:58.380 --> 06:02.230 align:middle line:90%
is on a wire between the
client and the edge router.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

140
05:58.380 --> 06:02.230 align:middle line:90%
is on a wire between the
client and the edge router.

141
06:02.230 --> 06:05.190 align:middle line:90%
So if we want to find
some traffic here,

142
06:05.190 --> 06:07.840 align:middle line:90%
there's a whole bunch of
ICMP that looks great.

143
06:07.840 --> 06:11.220 align:middle line:90%
In fact, there we go
1042, let's do a filter

144
06:11.220 --> 06:13.060 align:middle line:84%
on the size of the packet.

145
06:13.060 --> 06:14.790 align:middle line:90%
So I've just entered
a filter to set

146
06:14.790 --> 06:18.730 align:middle line:90%
anything greater than 1,000,
and there's our ping request.

147
06:18.730 --> 06:21.633 align:middle line:90%
We also have some TCP traffic
that's larger than 1,000.

148
06:21.633 --> 06:23.300 align:middle line:90%
All right, so that'll
help a little bit.

149
06:23.300 --> 06:25.200 align:middle line:90%
So this is the
pre-traffic, we grab

150
06:25.200 --> 06:29.270 align:middle line:90%
one of these from
10.1.0.50 to 10.2.0.50,

151
06:29.270 --> 06:33.010 align:middle line:90%
and if we look at the
details, this is ICMP traffic.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

151
06:29.270 --> 06:33.010 align:middle line:90%
and if we look at the
details, this is ICMP traffic.

152
06:33.010 --> 06:34.860 align:middle line:90%
So if we look at the
same set of traffic

153
06:34.860 --> 06:37.057 align:middle line:90%
after IPsec has
happened to it, we

154
06:37.057 --> 06:39.390 align:middle line:90%
should have the same source
and destination IP addresses

155
06:39.390 --> 06:42.420 align:middle line:90%
but with an ESP header protocol
50 and then beyond that,

156
06:42.420 --> 06:44.250 align:middle line:84%
all the payload is encrypted.

157
06:44.250 --> 06:45.990 align:middle line:90%
So let's check that
out, so I'm going

158
06:45.990 --> 06:49.140 align:middle line:90%
to go ahead and grab that
filter, right click, copy it,

159
06:49.140 --> 06:50.730 align:middle line:90%
and I'm going to use everything
over here and the second one

160
06:50.730 --> 06:52.313 align:middle line:90%
as well, so I'll
filter out everything

161
06:52.313 --> 06:55.180 align:middle line:84%
less than 1,000 bytes.

162
06:55.180 --> 06:58.630 align:middle line:90%
So we'll go ahead and
go to apply that filter.

163
06:58.630 --> 06:59.500 align:middle line:84%
And look at that.

164
06:59.500 --> 07:01.148 align:middle line:90%
So here, we have all
this ESP traffic,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

164
06:59.500 --> 07:01.148 align:middle line:90%
So here, we have all
this ESP traffic,

165
07:01.148 --> 07:03.690 align:middle line:90%
so the packets are going to be
a little bit bigger because we

166
07:03.690 --> 07:06.420 align:middle line:90%
have the encapsulation
with the ESP header

167
07:06.420 --> 07:09.540 align:middle line:90%
and then the new outside IP
header which is same addresses

168
07:09.540 --> 07:11.470 align:middle line:84%
involved that's been applied.

169
07:11.470 --> 07:14.390 align:middle line:90%
So it can be a little bit
bigger but we have 1126 here,

170
07:14.390 --> 07:18.630 align:middle line:90%
and we have 1510, so I think
this was our TCP traffic,

171
07:18.630 --> 07:20.640 align:middle line:84%
and these were our ICMP traffic.

172
07:20.640 --> 07:22.783 align:middle line:90%
However, if we look at
the details at layer 3,

173
07:22.783 --> 07:25.200 align:middle line:90%
it has a source and destination
addresses, not a surprise,

174
07:25.200 --> 07:28.050 align:middle line:90%
but if we take a look at
the next protocol, which

175
07:28.050 --> 07:30.900 align:middle line:90%
is protocol 50 and we
look at the header there,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

175
07:28.050 --> 07:30.900 align:middle line:90%
is protocol 50 and we
look at the header there,

176
07:30.900 --> 07:35.070 align:middle line:90%
it's ESP and then the
payload, is all encrypted.

177
07:35.070 --> 07:38.610 align:middle line:90%
So if we did a view and we
looked at the packet bytes

178
07:38.610 --> 07:41.910 align:middle line:90%
as well, this is just a
bunch of gobbledygook,

179
07:41.910 --> 07:43.650 align:middle line:90%
we can't make sense
of what that is.

180
07:43.650 --> 07:45.780 align:middle line:90%
It could be a HTTP
traffic for all we know,

181
07:45.780 --> 07:48.210 align:middle line:90%
or it could be a ICMP
payload, we don't know,

182
07:48.210 --> 07:51.500 align:middle line:90%
it's all encrypted, so it will
be decrypted on the other side

183
07:51.500 --> 07:54.040 align:middle line:90%
and then forwarded on to
its final destination.

184
07:54.040 --> 07:56.248 align:middle line:90%
So in this video we've taken
a look at some commands,

185
07:56.248 --> 07:59.580 align:middle line:90%
we can use at the CLI to verify
our get VPN implementation

186
07:59.580 --> 08:02.070 align:middle line:90%
and also, verify its
workings with some pre--
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

186
07:59.580 --> 08:02.070 align:middle line:90%
and also, verify its
workings with some pre--

187
08:02.070 --> 08:04.775 align:middle line:90%
and during captures
regarding the actual traffic.

188
08:04.775 --> 08:06.400 align:middle line:90%
So Thanks for joining
me in this video,

189
08:06.400 --> 08:07.950 align:middle line:90%
and I'll see you
in the next one.

190
08:07.950 --> 08:10.470 align:middle line:90%
Meanwhile, I hope this has
been informative for you,

191
08:10.470 --> 08:13.730 align:middle line:90%
and I'd like to thank
you for viewing.