WEBVTT

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


2
00:00.995 --> 00:02.620 align:middle line:90%
In this video, we're
going to both test

3
00:02.620 --> 00:05.860 align:middle line:90%
and verify the remote access
VPN from the perspective

4
00:05.860 --> 00:08.680 align:middle line:90%
of the client and also the
headend device R1, who's

5
00:08.680 --> 00:10.638 align:middle line:84%
acting as our VPN server.

6
00:10.638 --> 00:12.680 align:middle line:90%
So, from the client let's
get this party started.

7
00:12.680 --> 00:14.890 align:middle line:90%
Let's go and launch
the AnyConnect client

8
00:14.890 --> 00:18.370 align:middle line:90%
and from our profiles, I'm
going to choose profile 7.

9
00:18.370 --> 00:20.400 align:middle line:90%
There's a little
pre-connect reminder message

10
00:20.400 --> 00:22.330 align:middle line:90%
I had set up as
part of that profile

11
00:22.330 --> 00:25.240 align:middle line:90%
and now it's reaching
out to 15.1.1.1.

12
00:25.240 --> 00:26.740 align:middle line:90%
And hopefully in a
moment it's going

13
00:26.740 --> 00:27.823 align:middle line:84%
to ask us to authenticate.

14
00:27.823 --> 00:30.490 align:middle line:90%
Now, as we authenticate
the server, the server side
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

14
00:27.823 --> 00:30.490 align:middle line:90%
Now, as we authenticate
the server, the server side

15
00:30.490 --> 00:33.150 align:middle line:90%
it's using RSA signatures,
but this client,

16
00:33.150 --> 00:36.250 align:middle line:90%
that I'm sitting at,
doesn't know the CA

17
00:36.250 --> 00:37.490 align:middle line:84%
who signed the certificate.

18
00:37.490 --> 00:39.865 align:middle line:90%
So, it's very likely we're
going to get a message saying,

19
00:39.865 --> 00:41.680 align:middle line:90%
hey, you know what,
I can't really

20
00:41.680 --> 00:44.020 align:middle line:90%
verify this headend
server, are you sure

21
00:44.020 --> 00:45.790 align:middle line:84%
you want to still continue.

22
00:45.790 --> 00:46.640 align:middle line:84%
And there it is.

23
00:46.640 --> 00:48.550 align:middle line:90%
So, in a corporate
environment we'd

24
00:48.550 --> 00:51.340 align:middle line:90%
want to make sure that our
client machines trusted

25
00:51.340 --> 00:54.490 align:middle line:90%
the CA server who signed
the headend devices

26
00:54.490 --> 00:55.790 align:middle line:84%
digital certificate.

27
00:55.790 --> 00:58.210 align:middle line:90%
So, in this case I'm going
to click on connect anyway.

28
00:58.210 --> 01:00.760 align:middle line:90%
It's going to ask us to
authenticate, which we will.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

28
00:58.210 --> 01:00.760 align:middle line:90%
It's going to ask us to
authenticate, which we will.

29
01:00.760 --> 01:04.300 align:middle line:90%
We only have one user in the
local router and that's admin.

30
01:04.300 --> 01:07.040 align:middle line:90%
So, supply those
credentials, press Enter,

31
01:07.040 --> 01:09.250 align:middle line:90%
and it's establishing
the VPN connection.

32
01:09.250 --> 01:11.920 align:middle line:90%
Now, let me show you some
really amazing stuff.

33
01:11.920 --> 01:13.595 align:middle line:90%
If we click on this
gear icon, it's

34
01:13.595 --> 01:15.220 align:middle line:90%
going to show us some
details regarding

35
01:15.220 --> 01:16.630 align:middle line:84%
what's currently happening.

36
01:16.630 --> 01:18.430 align:middle line:90%
This right here
is our IP address

37
01:18.430 --> 01:20.770 align:middle line:90%
that we've been assigned
from the headend device that

38
01:20.770 --> 01:22.510 align:middle line:84%
was from the pool we set up.

39
01:22.510 --> 01:24.430 align:middle line:90%
Here's the server
we're connected to.

40
01:24.430 --> 01:27.057 align:middle line:90%
Our tunneling policy is
a split tunnel policy.

41
01:27.057 --> 01:29.140 align:middle line:90%
And if we want to see the
details for that policy,

42
01:29.140 --> 01:30.265 align:middle line:84%
we can go to route details.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

42
01:29.140 --> 01:30.265 align:middle line:84%
we can go to route details.

43
01:30.265 --> 01:33.490 align:middle line:90%
And here it shows us, yeah,
traffic going to 10 anything

44
01:33.490 --> 01:35.380 align:middle line:90%
is going to be going
through the tunnel,

45
01:35.380 --> 01:37.820 align:middle line:90%
and also traffic to the
DNS server you specified

46
01:37.820 --> 01:40.150 align:middle line:90%
of 10.5.5.5 will also
go through the tunnel,

47
01:40.150 --> 01:41.380 align:middle line:84%
everything else will not.

48
01:41.380 --> 01:44.140 align:middle line:90%
So, if we go back to
statistics and we scroll down

49
01:44.140 --> 01:47.170 align:middle line:90%
a little bit, here it has
details about bytes and bytes

50
01:47.170 --> 01:47.930 align:middle line:84%
sent and received.

51
01:47.930 --> 01:50.410 align:middle line:90%
So, right now we're not
receiving a whole bunch

52
01:50.410 --> 01:51.680 align:middle line:84%
of traffic through the tunnel.

53
01:51.680 --> 01:52.910 align:middle line:84%
Well, why is that?

54
01:52.910 --> 01:53.920 align:middle line:84%
Well, check this out.

55
01:53.920 --> 01:57.240 align:middle line:90%
Because our split tunnel policy
says only traffic going from 10

56
01:57.240 --> 02:00.040 align:middle line:90%
should go through the tunnel,
or for our traffic going to 10,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

56
01:57.240 --> 02:00.040 align:middle line:90%
should go through the tunnel,
or for our traffic going to 10,

57
02:00.040 --> 02:03.070 align:middle line:90%
we could actually generate
some traffic if we from this PC

58
02:03.070 --> 02:08.020 align:middle line:90%
went to 10.1.0.50, that happens
to be the IP address of PC1.

59
02:08.020 --> 02:10.020 align:middle line:90%
So, that traffic would
go through the tunnel,

60
02:10.020 --> 02:12.580 align:middle line:90%
the router would
de-encapsulate that, forward

61
02:12.580 --> 02:14.830 align:middle line:90%
it up to the server
who would then--

62
02:14.830 --> 02:16.330 align:middle line:90%
and it would look
like it was coming

63
02:16.330 --> 02:19.930 align:middle line:90%
from our virtual
address, the 10.67.83.,

64
02:19.930 --> 02:23.300 align:middle line:90%
I think it was 52 that
we saw a moment ago.

65
02:23.300 --> 02:26.860 align:middle line:90%
So, the server would see this
packet coming from 10.67.83.52,

66
02:26.860 --> 02:28.600 align:middle line:90%
it would forward it
out probably based

67
02:28.600 --> 02:31.017 align:middle line:90%
on its default gateway saying,
I don't know where that is.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

67
02:28.600 --> 02:31.017 align:middle line:90%
on its default gateway saying,
I don't know where that is.

68
02:31.017 --> 02:32.860 align:middle line:90%
The router says, oh,
I know where that is,

69
02:32.860 --> 02:35.590 align:middle line:90%
that's the VPN tunnel and it
would to encrypt the response

70
02:35.590 --> 02:37.750 align:middle line:90%
and send it back over
the tunnel over to the PC

71
02:37.750 --> 02:40.120 align:middle line:90%
where the AnyConnect client
would decrypt it and then

72
02:40.120 --> 02:41.823 align:middle line:84%
process the packet normally.

73
02:41.823 --> 02:43.240 align:middle line:90%
So, how do we
verify some of that.

74
02:43.240 --> 02:44.780 align:middle line:84%
Let's go back to the client.

75
02:44.780 --> 02:47.830 align:middle line:90%
So, here at the client let's go
to a command prompt that would

76
02:47.830 --> 02:49.910 align:middle line:84%
be really fun, lets do CMD.

77
02:49.910 --> 02:51.880 align:middle line:90%
And at a command prompt
if we did a show--

78
02:51.880 --> 02:53.950 align:middle line:84%
not show, we did a route print--

79
02:53.950 --> 02:56.150 align:middle line:90%
take a look at the routing
table, check this out.

80
02:56.150 --> 02:56.920 align:middle line:84%
Look at this.

81
02:56.920 --> 03:00.150 align:middle line:90%
This says right here that
we have a route to 10
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

81
02:56.920 --> 03:00.150 align:middle line:90%
This says right here that
we have a route to 10

82
03:00.150 --> 03:02.260 align:middle line:90%
and it's going through
our interface that has

83
03:02.260 --> 03:05.290 align:middle line:84%
the IP address of 10.67.83.52.

84
03:05.290 --> 03:07.040 align:middle line:90%
That is that virtual
address that we've

85
03:07.040 --> 03:09.250 align:middle line:90%
been signed, or been
assigned, and its

86
03:09.250 --> 03:13.310 align:middle line:90%
associated with our logical VPN
adapter, our AnyConnect client.

87
03:13.310 --> 03:17.070 align:middle line:90%
So, if we did a
ping to 10.1.0.50--

88
03:17.070 --> 03:19.600 align:middle line:90%
and I'm not at a privilege
prompt-- all right let's

89
03:19.600 --> 03:22.687 align:middle line:84%
just do a ping to 10.1.0.50.

90
03:22.687 --> 03:24.520 align:middle line:90%
That traffic should be
going over the tunnel

91
03:24.520 --> 03:27.610 align:middle line:90%
if we look at our counters
here, they should be increasing.

92
03:27.610 --> 03:28.280 align:middle line:84%
Awesome.

93
03:28.280 --> 03:31.550 align:middle line:90%
Those are received packets
that came back from the server.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

93
03:28.280 --> 03:31.550 align:middle line:90%
Those are received packets
that came back from the server.

94
03:31.550 --> 03:33.423 align:middle line:84%
So, if we do that again.

95
03:33.423 --> 03:34.840 align:middle line:90%
So, if we're doing
four packets it

96
03:34.840 --> 03:36.640 align:middle line:90%
should increase by
four, right there.

97
03:36.640 --> 03:38.950 align:middle line:90%
OK, so that was 8
and we did it again.

98
03:38.950 --> 03:44.260 align:middle line:90%
It should go to 12 coming back
and there it is right there,

99
03:44.260 --> 03:44.950 align:middle line:84%
fantastic.

100
03:44.950 --> 03:47.030 align:middle line:90%
So, that's from a
client perspective.

101
03:47.030 --> 03:49.803 align:middle line:90%
And if we ping something else,
like we did a ping over to--

102
03:49.803 --> 03:50.970 align:middle line:84%
what else we have out there.

103
03:50.970 --> 03:52.845 align:middle line:90%
Let me take a look at
my topology real quick.

104
03:52.845 --> 03:55.720 align:middle line:90%
So, if we did a ping 25.2.2.2,
because it doesn't match

105
03:55.720 --> 03:57.298 align:middle line:90%
our split tunnel
policy, that traffic

106
03:57.298 --> 03:59.590 align:middle line:90%
would just be sent normally
from the physical interface

107
03:59.590 --> 04:02.260 align:middle line:90%
on the PC to the
destination address
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

107
03:59.590 --> 04:02.260 align:middle line:90%
on the PC to the
destination address

108
04:02.260 --> 04:03.640 align:middle line:90%
without going
through the tunnel.

109
04:03.640 --> 04:05.765 align:middle line:90%
All right, so that's from
the client's perspective.

110
04:05.765 --> 04:08.660 align:middle line:90%
Let's go take a look at
the headend router itself.

111
04:08.660 --> 04:10.500 align:middle line:90%
So, here on the router,
the headend device,

112
04:10.500 --> 04:14.150 align:middle line:90%
I have a message that says that
the Virtual-Access1 changed

113
04:14.150 --> 04:15.280 align:middle line:84%
state to up.

114
04:15.280 --> 04:17.440 align:middle line:90%
So, if we did a show
IP interface brief--

115
04:17.440 --> 04:18.290 align:middle line:84%
let's do that.

116
04:18.290 --> 04:20.829 align:middle line:90%
So, we have this virtual
template and it's down.

117
04:20.829 --> 04:22.810 align:middle line:90%
If we scroll to the
right, it's down.

118
04:22.810 --> 04:24.460 align:middle line:84%
And when they have the client--

119
04:24.460 --> 04:26.560 align:middle line:90%
in this case admin--
who connected,

120
04:26.560 --> 04:28.420 align:middle line:90%
it spun off of that
virtual template

121
04:28.420 --> 04:30.790 align:middle line:90%
a new logical virtual
access interface
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

121
04:28.420 --> 04:30.790 align:middle line:90%
a new logical virtual
access interface

122
04:30.790 --> 04:32.860 align:middle line:90%
right here using
the same IP address

123
04:32.860 --> 04:37.360 align:middle line:90%
because we said IPN numbered,
go ahead and use loopback 100.

124
04:37.360 --> 04:39.730 align:middle line:90%
So, the template is using
IPN numbered pointed

125
04:39.730 --> 04:43.240 align:middle line:90%
to loopback 100 for that address
and this new virtual access

126
04:43.240 --> 04:45.940 align:middle line:90%
interface that was
created from the template

127
04:45.940 --> 04:47.720 align:middle line:84%
is using that same information.

128
04:47.720 --> 04:50.710 align:middle line:90%
So, this Virtual-Access1
interface is up

129
04:50.710 --> 04:52.570 align:middle line:90%
and that's the
logical connection

130
04:52.570 --> 04:54.730 align:middle line:90%
that our VPN client
is coming in from.

131
04:54.730 --> 04:56.760 align:middle line:90%
So, a couple of cool
things that we can do.

132
04:56.760 --> 04:59.320 align:middle line:90%
Check this, to
also show IP route.

133
04:59.320 --> 05:00.480 align:middle line:84%
So, to show IP route--
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

133
04:59.320 --> 05:00.480 align:middle line:84%
So, to show IP route--

134
05:00.480 --> 05:01.980 align:middle line:90%
so check out the
routing table here.

135
05:01.980 --> 05:04.590 align:middle line:90%
We have this entry
for 10.67.83.52,

136
05:04.590 --> 05:06.270 align:middle line:84%
does that look familiar.

137
05:06.270 --> 05:08.820 align:middle line:90%
That is the IKE address,
the virtual IP address that

138
05:08.820 --> 05:10.743 align:middle line:84%
is assigned to our VPN client.

139
05:10.743 --> 05:13.160 align:middle line:90%
So, when it's routing table
says, well if I get a packet--

140
05:13.160 --> 05:14.830 align:middle line:90%
let's say that a
client went to a server

141
05:14.830 --> 05:16.410 align:middle line:90%
and the server's
responding back--

142
05:16.410 --> 05:18.130 align:middle line:90%
if I get a packet
to this address,

143
05:18.130 --> 05:19.210 align:middle line:84%
I know how to reach it.

144
05:19.210 --> 05:22.740 align:middle line:90%
It's Virtual-Access1,
which is my virtual access

145
05:22.740 --> 05:26.040 align:middle line:90%
logical interface created from
the template for the benefit

146
05:26.040 --> 05:28.610 align:middle line:90%
of supporting that
remote access VPN client.

147
05:28.610 --> 05:32.478 align:middle line:90%
We can also do a show
crypto IKE version 2 SA
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

147
05:28.610 --> 05:32.478 align:middle line:90%
We can also do a show
crypto IKE version 2 SA

148
05:32.478 --> 05:34.020 align:middle line:90%
and there is our
security association

149
05:34.020 --> 05:35.140 align:middle line:84%
that we currently have.

150
05:35.140 --> 05:38.070 align:middle line:90%
So, the remote
client's at 10.5.5.51,

151
05:38.070 --> 05:39.480 align:middle line:84%
that's it's IP address.

152
05:39.480 --> 05:41.730 align:middle line:84%
Notice here it shows 4,500.

153
05:41.730 --> 05:45.600 align:middle line:90%
So, with IPsec, if it notices
and if NAT traversal is

154
05:45.600 --> 05:48.000 align:middle line:90%
enabled, which it is, and
it knows that hey there

155
05:48.000 --> 05:51.150 align:middle line:90%
may be NAT between us
and the destination,

156
05:51.150 --> 05:53.940 align:middle line:90%
it will [INAUDIBLE] instead
of using ESP protocol 50,

157
05:53.940 --> 05:57.690 align:middle line:90%
it'll prepend that
with a UDP port 4,500

158
05:57.690 --> 06:00.150 align:middle line:90%
for the benefit of getting
through PAT devices that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

158
05:57.690 --> 06:00.150 align:middle line:90%
for the benefit of getting
through PAT devices that

159
06:00.150 --> 06:03.690 align:middle line:90%
otherwise may not know how
to correctly handle ESP

160
06:03.690 --> 06:06.250 align:middle line:84%
with port address translation.

161
06:06.250 --> 06:09.090 align:middle line:90%
And if we do that same
command again with the detail

162
06:09.090 --> 06:11.770 align:middle line:90%
it's going to show us the
details for that session.

163
06:11.770 --> 06:14.040 align:middle line:90%
So, there is the
server's IP address,

164
06:14.040 --> 06:16.440 align:middle line:90%
that's the IP address
of our VPN client,

165
06:16.440 --> 06:18.780 align:middle line:90%
and there's the virtual
address that we assign

166
06:18.780 --> 06:20.880 align:middle line:84%
to that client from that pool.

167
06:20.880 --> 06:22.110 align:middle line:84%
And so, that's for IKEv2.

168
06:22.110 --> 06:27.035 align:middle line:90%
If we did a show crypto IPsec
essay and pressed enter,

169
06:27.035 --> 06:28.410 align:middle line:90%
there it shows us
the information

170
06:28.410 --> 06:31.630 align:middle line:90%
for Virtual-Access1,
including the encapsulations,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

170
06:28.410 --> 06:31.630 align:middle line:90%
for Virtual-Access1,
including the encapsulations,

171
06:31.630 --> 06:34.510 align:middle line:90%
and de-encapsulations, and
the endpoints of the tunnel.

172
06:34.510 --> 06:37.950 align:middle line:90%
So, this is R1 itself
and this is the VPN

173
06:37.950 --> 06:39.500 align:middle line:84%
client and in the area--

174
06:39.500 --> 06:42.420 align:middle line:90%
[LAUGHTER]---- on the internet a
client coming in would appear

175
06:42.420 --> 06:44.910 align:middle line:90%
to be coming from a
publicly routable address.

176
06:44.910 --> 06:48.270 align:middle line:90%
In my lab I use the 10.5.5
network or the public internet.

177
06:48.270 --> 06:50.160 align:middle line:90%
That would be a publicly
reachable address

178
06:50.160 --> 06:51.690 align:middle line:84%
as that device goes through NAT.

179
06:51.690 --> 06:53.273 align:middle line:90%
So, in this video
we've had the chance

180
06:53.273 --> 06:56.850 align:middle line:90%
to take a look at the results of
our VPN tunnel from both sides.

181
06:56.850 --> 06:59.370 align:middle line:90%
From the headend side, the R1
who's acting as our headend

182
06:59.370 --> 07:02.290 align:middle line:90%
VPN server, and also from
the AnyConnect client.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

182
06:59.370 --> 07:02.290 align:middle line:90%
VPN server, and also from
the AnyConnect client.

183
07:02.290 --> 07:03.790 align:middle line:90%
Thanks for joining
me in this video.

184
07:03.790 --> 07:04.930 align:middle line:84%
I'll see you in the next.

185
07:04.930 --> 07:07.410 align:middle line:90%
Meanwhile, I hope this has
been informative for you

186
07:07.410 --> 07:10.500 align:middle line:90%
and I'd like to thank
you for viewing.

187
07:10.500 --> 07:11.000 align:middle line:84%