In this video, we're going to both test
and verify the remote access VPN from the perspective
of the client and also the headend device R1, who's
acting as our VPN server.
So, from the client let's get this party started.
Let's go and launch the AnyConnect client
and from our profiles, I'm going to choose profile 7.
There's a little pre-connect reminder message
I had set up as part of that profile
and now it's reaching out to 15.1.1.1.
And hopefully in a moment it's going
to ask us to authenticate.
Now, as we authenticate the server, the server side WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now, as we authenticate the server, the server side
it's using RSA signatures, but this client,
that I'm sitting at, doesn't know the CA
who signed the certificate.
So, it's very likely we're going to get a message saying,
hey, you know what, I can't really
verify this headend server, are you sure
you want to still continue.
And there it is.
So, in a corporate environment we'd
want to make sure that our client machines trusted
the CA server who signed the headend devices
digital certificate.
So, in this case I'm going to click on connect anyway.
It's going to ask us to authenticate, which we will. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's going to ask us to authenticate, which we will.
We only have one user in the local router and that's admin.
So, supply those credentials, press Enter,
and it's establishing the VPN connection.
Now, let me show you some really amazing stuff.
If we click on this gear icon, it's
going to show us some details regarding
what's currently happening.
This right here is our IP address
that we've been assigned from the headend device that
was from the pool we set up.
Here's the server we're connected to.
Our tunneling policy is a split tunnel policy.
And if we want to see the details for that policy,
we can go to route details. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we can go to route details.
And here it shows us, yeah, traffic going to 10 anything
is going to be going through the tunnel,
and also traffic to the DNS server you specified
of 10.5.5.5 will also go through the tunnel,
everything else will not.
So, if we go back to statistics and we scroll down
a little bit, here it has details about bytes and bytes
sent and received.
So, right now we're not receiving a whole bunch
of traffic through the tunnel.
Well, why is that?
Well, check this out.
Because our split tunnel policy says only traffic going from 10
should go through the tunnel, or for our traffic going to 10, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
should go through the tunnel, or for our traffic going to 10,
we could actually generate some traffic if we from this PC
went to 10.1.0.50, that happens to be the IP address of PC1.
So, that traffic would go through the tunnel,
the router would de-encapsulate that, forward
it up to the server who would then--
and it would look like it was coming
from our virtual address, the 10.67.83.,
I think it was 52 that we saw a moment ago.
So, the server would see this packet coming from 10.67.83.52,
it would forward it out probably based
on its default gateway saying, I don't know where that is. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
on its default gateway saying, I don't know where that is.
The router says, oh, I know where that is,
that's the VPN tunnel and it would to encrypt the response
and send it back over the tunnel over to the PC
where the AnyConnect client would decrypt it and then
process the packet normally.
So, how do we verify some of that.
Let's go back to the client.
So, here at the client let's go to a command prompt that would
be really fun, lets do CMD.
And at a command prompt if we did a show--
not show, we did a route print--
take a look at the routing table, check this out.
Look at this.
This says right here that we have a route to 10 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This says right here that we have a route to 10
and it's going through our interface that has
the IP address of 10.67.83.52.
That is that virtual address that we've
been signed, or been assigned, and its
associated with our logical VPN adapter, our AnyConnect client.
So, if we did a ping to 10.1.0.50--
and I'm not at a privilege prompt-- all right let's
just do a ping to 10.1.0.50.
That traffic should be going over the tunnel
if we look at our counters here, they should be increasing.
Awesome.
Those are received packets that came back from the server. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Those are received packets that came back from the server.
So, if we do that again.
So, if we're doing four packets it
should increase by four, right there.
OK, so that was 8 and we did it again.
It should go to 12 coming back and there it is right there,
fantastic.
So, that's from a client perspective.
And if we ping something else, like we did a ping over to--
what else we have out there.
Let me take a look at my topology real quick.
So, if we did a ping 25.2.2.2, because it doesn't match
our split tunnel policy, that traffic
would just be sent normally from the physical interface
on the PC to the destination address WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
on the PC to the destination address
without going through the tunnel.
All right, so that's from the client's perspective.
Let's go take a look at the headend router itself.
So, here on the router, the headend device,
I have a message that says that the Virtual-Access1 changed
state to up.
So, if we did a show IP interface brief--
let's do that.
So, we have this virtual template and it's down.
If we scroll to the right, it's down.
And when they have the client--
in this case admin-- who connected,
it spun off of that virtual template
a new logical virtual access interface WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a new logical virtual access interface
right here using the same IP address
because we said IPN numbered, go ahead and use loopback 100.
So, the template is using IPN numbered pointed
to loopback 100 for that address and this new virtual access
interface that was created from the template
is using that same information.
So, this Virtual-Access1 interface is up
and that's the logical connection
that our VPN client is coming in from.
So, a couple of cool things that we can do.
Check this, to also show IP route.
So, to show IP route-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So, to show IP route--
so check out the routing table here.
We have this entry for 10.67.83.52,
does that look familiar.
That is the IKE address, the virtual IP address that
is assigned to our VPN client.
So, when it's routing table says, well if I get a packet--
let's say that a client went to a server
and the server's responding back--
if I get a packet to this address,
I know how to reach it.
It's Virtual-Access1, which is my virtual access
logical interface created from the template for the benefit
of supporting that remote access VPN client.
We can also do a show crypto IKE version 2 SA WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We can also do a show crypto IKE version 2 SA
and there is our security association
that we currently have.
So, the remote client's at 10.5.5.51,
that's it's IP address.
Notice here it shows 4,500.
So, with IPsec, if it notices and if NAT traversal is
enabled, which it is, and it knows that hey there
may be NAT between us and the destination,
it will [INAUDIBLE] instead of using ESP protocol 50,
it'll prepend that with a UDP port 4,500
for the benefit of getting through PAT devices that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for the benefit of getting through PAT devices that
otherwise may not know how to correctly handle ESP
with port address translation.
And if we do that same command again with the detail
it's going to show us the details for that session.
So, there is the server's IP address,
that's the IP address of our VPN client,
and there's the virtual address that we assign
to that client from that pool.
And so, that's for IKEv2.
If we did a show crypto IPsec essay and pressed enter,
there it shows us the information
for Virtual-Access1, including the encapsulations, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for Virtual-Access1, including the encapsulations,
and de-encapsulations, and the endpoints of the tunnel.
So, this is R1 itself and this is the VPN
client and in the area--
[LAUGHTER]---- on the internet a client coming in would appear
to be coming from a publicly routable address.
In my lab I use the 10.5.5 network or the public internet.
That would be a publicly reachable address
as that device goes through NAT.
So, in this video we've had the chance
to take a look at the results of our VPN tunnel from both sides.
From the headend side, the R1 who's acting as our headend
VPN server, and also from the AnyConnect client. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
VPN server, and also from the AnyConnect client.
Thanks for joining me in this video.
I'll see you in the next.
Meanwhile, I hope this has been informative for you
and I'd like to thank you for viewing.