In this video, I'd like to chat with you about some
of the common protocols that we'll often
find in methods that are used when implementing remote access
VPNs, including in a Cisco environment.
So let's start off with this topology.
We've got a user that says Bob down here,
and let's use R1 as a head-end device.
And this would give me the corporate side of our VPN
tunnel right here, R1.
So as far as the technologies to protect
the traffic for our VPNs, we could use IPSec.
That's certainly an option.
We can also use the TLS flavor, which is SSL/TLS, TLS being WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We can also use the TLS flavor, which is SSL/TLS, TLS being
the more secure option there.
But both of these can be used for remote access VPNs.
Now if we were making a list of those things
that we would like, a wish list for those things
that we'd like to be able to do with a remote access VPN
from our perspective, from the administration perspective,
it would be a great idea if we could push.
What do you mean, Keith, push?
If we could push policy down to the VPN client.
So when they connect, of course, we would authenticate them,
make sure we know who they are, before we just
build a VPN with anybody.
But once we authenticate them, it'd WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But once we authenticate them, it'd
be great if we could push policy down regarding routing.
And here's what I mean by that.
If we have over here the 10 network behind R1,
and this is our VPN server, and this device here
would be our VPN client, referring
to the device like Bob's computer,
if we want to protect the traffic between Bob's
computer and the 10 networks, we could push down routing policy
and say, you know what, if you need
to reach the 10 anything network,
go ahead and send that traffic over the tunnel.
And we could push that policy down.
And as long as that VPN's up, he'll follow his instructions. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And as long as that VPN's up, he'll follow his instructions.
So traffic to the 10 network would go over the tunnel,
whereas traffic that's like for Netflix or something else
wouldn't go over the tunnel.
The destination address would be 10.
And as a result, that computer with the VPN client software
running would simply forward it out naked and not
send it over the tunnel.
Now that's referred to as a concept of split tunneling.
And most companies are using some flavor of that.
Why is that?
Because there's too much traffic to send everything
over the tunnel.
If we wanted Bob to do a full tunnel, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If we wanted Bob to do a full tunnel,
if he's going to Netflix while the VPN happens to be up,
his traffic for Netflix would go to the corporate server,
encrypted.
The server would flip that around and send it out
naked out to the internet, to Netflix.
That traffic would have to go back to the head-end device,
and then back encrypted through the tunnel back to Bob.
No.
Nobody asked for that.
So split tunneling is the way to go for most implementations.
If he had some kind of a really high secure environment, where
everything has to be sent through the tunnel
for inspection and so forth, that might be a business case.
But most companies are going to be doing split tunneling, based WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But most companies are going to be doing split tunneling, based
on pushing routing policy down.
We can also push down policies such as firewalls
and other restrictions.
So that while the VPN client is running,
it can enforce those policies that have been pushed down
from the VPN server.
Now in a Cisco environment, the primary software
we're going to use as a VPN client is the Cisco AnyConnect
client.
And it can support SSL/TLS.
It can support IPSec.
So we have a profile letter, which
we can create profiles, and then have
our clients go ahead and use those profiles for, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
our clients go ahead and use those profiles for,
based on how we want them to connect for the VPN,
whether-- is it SSL or is it IPSec?
And if so, what's the server IP addresses?
Who's our backup server and so forth?
Now VPNs, of course, are not restricted
to using a literal software client
because we might have some software that's
built into the operating system that could also
be used as part of a VPN.
So that depends on like Apple or Windows or a Linux
and what their clients and what their operating
systems are capable of.
But most of the time, if you're using a Cisco solution,
you're going to use the AnyConnect client, which WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
you're going to use the AnyConnect client, which
integrates really well with Cisco's head-end devices,
including R1 as an IOS router that's acting as a VPN server.
So those are some options that we have for remote access VPNs,
but it doesn't have to be limited to a router acting
as the head-end device.
We can also have a Cisco ASA.
We could use a Firepower Threat Defense
system that's terminated that VPN tunnel, Check Point, Palo
Alto.
The list goes on.
There's lots of vendors--
Juniper, that support VPN solutions.
So in this video, we've taken a look
at some of the aspects and options for it. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
at some of the aspects and options for it.
In the next video, I'd like to take a look at using a Cisco
router with FlexVPN, and what's involved there
to support remote access VPNs.
So I'll see you there in just a moment.
Meanwhile, I hope this has been informative for you,
and I'd like to thank you for viewing.