|
0:00:14
|
In our next section we are going to look at a different variation of the IOS's easyVPN server configuration
|
|
0:00:20
|
where we are using Dynamic Virtual Tunnel Interfaces or DVTIs
|
|
0:00:25
|
in conjunction with the isakmp profiles
|
|
0:00:29
|
we will also look at another variation of easyvpn client that is using the Dynamic Virtual Tunnel Interfaces
|
|
0:00:35
|
as opposed to the dynamic crypto maps
|
|
0:00:41
|
now previously we saw this configuration with the virtual tunnel interfaces
|
|
0:00:45
|
when we were replacing a LAN-to-LAN ipsec tunnel
|
|
0:00:49
|
that was running between router1 and 3
|
|
0:00:52
|
that was also using GRE
|
|
0:00:55
|
for encapsulation
|
|
0:00:57
|
in order, for us to allow dynamic routing
|
|
0:01:00
|
from the LAN-to-LAN segments
|
|
0:01:02
|
where we were running eigrp
|
|
0:01:04
|
on the link between router3 and 4
|
|
0:01:07
|
we were running then eigrp on the tunnel interface
|
|
0:01:10
|
and then router1 was also advertising its routes over tunnel via the dynamic protocol
|
|
0:01:16
|
So the advantages of using the Static Virtual Tunnel Interface or the SVTI
|
|
0:01:21
|
is that we were maintaining
|
|
0:01:23
|
the ability to run a dynamic routing over the tunnel
|
|
0:01:26
|
but we were saving the additional overhead of the GRE encapsulation
|
|
0:01:32
|
Now we will see that the Dynamic Virtual Tunnel Interface is similar to this
|
|
0:01:35
|
where it gives us the advantage of having an interface associated with the ipsec tunnel
|
|
0:01:42
|
but we don't have the additional overhead
|
|
0:01:44
|
of running the GRE encapsulation
|
|
0:01:47
|
So in later sections when we get into the Dynamic Multipoint VPN with DMVPN
|
|
0:01:52
|
we will see one of the potential shortcoming to that design
|
|
0:01:56
|
is that you do have the additional GRE encapsulation
|
|
0:01:59
|
where when we look at this
|
|
0:02:00
|
for very high bandwidth application
|
|
0:02:02
|
it were talking about like 1 Giga bit per second or more
|
|
0:02:06
|
then there is a significant amount of bandwidth that is wasted on the extra overhead
|
|
0:02:11
|
So in these examples, we are going to be running router3 as the easyVPN server again
|
|
0:02:17
|
and we are going to be taking in two different types of connections
|
|
0:02:20
|
one of them is going to come from the test PC
|
|
0:02:22
|
that is running the actual software
|
|
0:02:24
|
VPN client on windows
|
|
0:02:26
|
and one that is coming router5 as the easyVPN remote
|
|
0:02:30
|
or the IOS's easyVPN client configuration
|
|
0:02:35
|
Now the key point of this design
|
|
0:02:37
|
with the easyVPN server and client
|
|
0:02:39
|
is that we can use
|
|
0:02:41
|
any combination of server configs or client configs
|
|
0:02:44
|
and end up in the same result
|
|
0:02:47
|
this is means that if the server is using the Dynamic VTI
|
|
0:02:51
|
the client can be using either the software client, like on our windows machine
|
|
0:02:56
|
it can be running the regular easyVPN client
|
|
0:03:00
|
and either client mode or network mode or network plus
|
|
0:03:04
|
but it could also be running the easyVPN client with the DVTIs
|
|
0:03:08
|
then likewise if router3 running other combination of the config
|
|
0:03:14
|
regardless whether we are using the Dynamic crypto maps or we are using the DVTIs
|
|
0:03:17
|
we are going to have
|
|
0:03:18
|
compatibilities between all of them
|
|
0:03:22
|
Now the reason that we will want to do this
|
|
0:03:25
|
in addition to have an interface
|
|
0:03:27
|
associated with the ipsec tunnel
|
|
0:03:30
|
its going to allow us to configure some additional features like QoS
|
|
0:03:34
|
or with the introduction of the isakmp profiles
|
|
0:03:37
|
we have some more granular control
|
|
0:03:40
|
over how one particular
|
|
0:03:42
|
client traffic is going to be treated versus another
|
|
0:03:46
|
so for example here, where we have the test PC
|
|
0:03:49
|
authenticating to the easyVPN server
|
|
0:03:53
|
based on the group authentication or based on the user authentication
|
|
0:03:57
|
we could assign this connection
|
|
0:03:59
|
to an isakmp
|
|
0:04:01
|
profile number 1
|
|
0:04:04
|
where this profile says, I am assigned to virtual tunnel interface 1
|
|
0:04:09
|
and based on that VTI I have certain QoS configurations
|
|
0:04:13
|
may be I have certain filtering configurations
|
|
0:04:16
|
where we could have
|
|
0:04:18
|
the second authentication that is coming in from router5
|
|
0:04:21
|
we could assign this to a different isakmp profile
|
|
0:04:23
|
that is going to have different QoS options, different security options etc
|
|
0:04:29
|
So we will see the combination of both the Virtual Tunnel Interface in the isakmp profile
|
|
0:04:34
|
is going to give us some more granular control
|
|
0:04:36
|
and a little bit more flexibility than using the Dynamic crypto maps
|
|
0:04:40
|
with the static isakmp policies
|
|
0:04:45
|
So next lets take a look at the documentation
|
|
0:04:48
|
and just like all of our other ipsec configurations, this is going to be under
|
|
0:04:52
|
the secure connectivity portion
|
|
0:04:55
|
of the security documentation
|
|
0:04:57
|
then this is going to be under ipsec
|
|
0:05:01
|
VPN security for VPNs with ipsec
|
|
0:05:03
|
and the IPSec Virtual Tunnel Interface
|
|
0:05:07
|
Now we do previously see this documentation before when we were configuring the static
|
|
0:05:12
|
Virtual Tunnel Interfaces
|
|
0:05:14
|
where again this is the replacement for the GRE tunnel
|
|
0:05:17
|
but its saving as that additional encapsulation overhead
|
|
0:05:21
|
then with the Dynamic
|
|
0:05:23
|
BGIs
|
|
0:05:24
|
this is going to be the replacement of the dynamic
|
|
0:05:26
|
crypto map inside the easyVPN server config
|
|
0:05:31
|
Now we will also see in some later examples
|
|
0:05:34
|
one of the additional advantages of using the Virtual Tunnel Interface
|
|
0:05:37
|
is that we can do VRF aware
|
|
0:05:40
|
ipsec
|
|
0:05:42
|
meaning that we have two separate tunnel interfaces or more
|
|
0:05:46
|
that are assigned to different virtual routing and forwarding interface
|
|
0:05:50
|
instances, excuse me, VRF instances
|
|
0:05:53
|
then depending on how the particular authentication works
|
|
0:05:57
|
the user is going to be assigned to one of these VTIs
|
|
0:06:00
|
that ultimately has a separate routing table
|
|
0:06:03
|
then the other VTIs
|
|
0:06:05
|
So we are doing security, not only in the data plane
|
|
0:06:09
|
with the actual encryption by using the ESP
|
|
0:06:12
|
or the ESP over UDP tunnel
|
|
0:06:16
|
but then we are also doing security in the control plane
|
|
0:06:19
|
by separating the routing information
|
|
0:06:22
|
of certain users versus others
|
|
0:06:26
|
So its multiple layer security, not only the data plane
|
|
0:06:30
|
with the tunnel but then actually the control plane with the routing
|
|
0:06:35
|
Now just like the other examples, we could go through the configuration task list
|
|
0:06:40
|
and look at how to configure the ipsec tunnel
|
|
0:06:42
|
how to configure dynamic ipsec
|
|
0:06:44
|
and its going to give us this numbered
|
|
0:06:47
|
step by step task list
|
|
0:06:49
|
but when we look at simply the example towards the end
|
|
0:06:53
|
the configuration example of the Dynamic VTI as an easy VPN server
|
|
0:06:58
|
we will see that a lot of the configuration is similar
|
|
0:07:01
|
to the previous
|
|
0:07:03
|
ipsec configs, whether they were the LAN-to-LAN or the remote access
|
|
0:07:08
|
because the same step by step process is always going to be true
|
|
0:07:12
|
that the first thing we need to do
|
|
0:07:14
|
is to find the phase I negotiation
|
|
0:07:17
|
that is still defined mainly by the isakmp policy
|
|
0:07:22
|
then we are going to define the phase II parameters
|
|
0:07:25
|
which are going to include
|
|
0:07:27
|
the crypto transform set
|
|
0:07:30
|
then if we are trying to do split tunnelling, we would have an access list
|
|
0:07:34
|
that defines
|
|
0:07:35
|
what is the proxy identity for that individual client
|
|
0:07:40
|
and as we know with the VPN server
|
|
0:07:43
|
we are not setting the peer address
|
|
0:07:45
|
because the responder who is the server
|
|
0:07:46
|
doesn't know who the initiator is, or who the client is to begin with
|
|
0:07:52
|
Now what changes with this configuration
|
|
0:07:55
|
is that there is no
|
|
0:07:56
|
crypto map that is applied to this interface
|
|
0:07:59
|
where instead we have a virtual template interface which is a type tunnel
|
|
0:08:03
|
and the tunnel mode is ipsec ipv4
|
|
0:08:08
|
and the crypto profile
|
|
0:08:10
|
is then applied to the tunnel
|
|
0:08:13
|
where its essentially saying that any traffic that routes to the tunnel
|
|
0:08:18
|
is then going to use this profile which in this case is calling test-vti1
|
|
0:08:23
|
and test-vti1 is then calling the transform set
|
|
0:08:27
|
which says that we are running 3DES with SHA
|
|
0:08:33
|
that was similar to our static
|
|
0:08:35
|
Virtual Tunnel Interface that we saw before
|
|
0:08:37
|
the next step then
|
|
0:08:39
|
is to associate the individual VPN users
|
|
0:08:42
|
with that tunnel interface
|
|
0:08:44
|
and thats mainly here what the ISAKMP profile is used for
|
|
0:08:50
|
where the ISAKMP profile says that when our phase I
|
|
0:08:53
|
negotiation occurs
|
|
0:08:56
|
and for the easy VPN we know that
|
|
0:08:58
|
portion of this negotiation
|
|
0:08:59
|
is to exchange what is the group name
|
|
0:09:03
|
and then what is the group authentication
|
|
0:09:05
|
where we have the pre shared key for the
|
|
0:09:07
|
the phase I authentication
|
|
0:09:11
|
so the user comes in, they are using group named group 1
|
|
0:09:15
|
they are going to authenticate with the password cisco123
|
|
0:09:18
|
then they are assigned to this particular isakmp profile
|
|
0:09:21
|
so is the profile's name is VPN1-RA
|
|
0:09:27
|
Now if we look at the sub options here under the isakmp profile
|
|
0:09:31
|
we could see just based on this basic example
|
|
0:09:34
|
some of the things that we can set with the AAA list
|
|
0:09:38
|
so how are we doing the authentication, how are we doing the authorization
|
|
0:09:42
|
then additionally, what is the interface
|
|
0:09:45
|
that the client is then going to be assigned to
|
|
0:09:49
|
so some of the things that this will allow us to do
|
|
0:09:52
|
is based on the AAA configuration
|
|
0:09:55
|
we could do different types of authentication or different types of authorisation
|
|
0:09:59
|
depending on what the group name is
|
|
0:10:02
|
where may be group number 1, I want to send this to my TACAC server
|
|
0:10:06
|
but for group number2, may be I am going to check the local database
|
|
0:10:10
|
then group number 3 I am going to go to a different Radius server
|
|
0:10:15
|
then additionally since I am also defining the virtual template
|
|
0:10:19
|
which is the actual Dynamic Virtual Tunnel Interface or the DVTI
|
|
0:10:24
|
I can then control the per interface parameters
|
|
0:10:28
|
based on the authentication
|
|
0:10:31
|
So some one comes in, the user comes in, using group number1
|
|
0:10:36
|
they are then assigned to virtual template1
|
|
0:10:38
|
which means that any QoS that I have configured on here
|
|
0:10:41
|
or may its part of a zone based policy firewall configuration
|
|
0:10:46
|
so once the easyVPN connects
|
|
0:10:48
|
we have a different firewall filtering policy for a certain type of user
|
|
0:10:52
|
versus other ones
|
|
0:10:54
|
may be we have a template for our administrators
|
|
0:10:57
|
that are allowed to telnet or SSH to the network devices
|
|
0:11:01
|
then one that is for the basic users, or may be I will say
|
|
0:11:04
|
allow them to use tcp port 80
|
|
0:11:07
|
and may be mail
|
|
0:11:09
|
traffic, like smtp or pop3 or imap
|
|
0:11:14
|
but the key is that since we are now
|
|
0:11:16
|
decoupling
|
|
0:11:17
|
the phase I authentication
|
|
0:11:21
|
and applying it on a per group basis
|
|
0:11:24
|
where normally this
|
|
0:11:26
|
this type of stuff will be global
|
|
0:11:27
|
for the particular crypto map
|
|
0:11:30
|
but since we are removing the crypto map
|
|
0:11:32
|
and then making it more modular
|
|
0:11:35
|
configuration logic
|
|
0:11:36
|
it gives us more flexibility to the final result of the configuration
|
|
0:11:43
|
So lets take this example that they have here
|
|
0:11:46
|
and lets change it around in order to match our particular design
|
|
0:11:58
|
Now again if we take a look back at that topology
|
|
0:12:01
|
I want to configure router3 as the server
|
|
0:12:04
|
so that it is listening for traffic coming in from the test PC
|
|
0:12:08
|
and from router5
|
|
0:12:10
|
and ultimately I want traffic that is going to the 172.16.34 network
|
|
0:12:16
|
and 172.16.4
|
|
0:12:18
|
network, I want that to go over the tunnel
|
|
0:12:23
|
so first lets remove some of the unnecessary
|
|
0:12:26
|
things we have here
|
|
0:12:28
|
like the ip subnet 0, the ip cef
|
|
0:12:31
|
you will see that
|
|
0:12:32
|
the configuration examples lot of the times will just leave
|
|
0:12:36
|
unrelated configs in
|
|
0:12:38
|
where this would be one of the first things that you would want to do, when you are
|
|
0:12:41
|
you are using there examples
|
|
0:12:43
|
try to minimize it, so that you have just the
|
|
0:12:45
|
the pieces of syntax that are really specific to that
|
|
0:12:48
|
individual feature
|
|
0:12:51
|
I don't need to know about
|
|
0:12:52
|
there interfaces that they are using for their connections
|
|
0:12:56
|
I do need to know about the virtual template though
|
|
0:12:59
|
that I have an address pool, I don't need to worry about their routing
|
|
0:13:04
|
so this here, this is going to be the most basic functionality
|
|
0:13:09
|
So now lets start with our phase I
|
|
0:13:12
|
and work up from there, we have a phase I policy
|
|
0:13:16
|
it says we are using 3DES encryption
|
|
0:13:20
|
pre shared authentication group number 2
|
|
0:13:23
|
and then the hash most likely is going to be default to SHA, in this IOS version
|
|
0:13:30
|
Now once the user comes in
|
|
0:13:32
|
and does the phase I authentication
|
|
0:13:34
|
we then need check their group information
|
|
0:13:38
|
so this is where the crypto isakmp client configuration group is
|
|
0:13:43
|
this name here
|
|
0:13:45
|
this is what we put into the VPN client
|
|
0:13:48
|
whether this be the IOS router
|
|
0:13:51
|
or whether this be the
|
|
0:13:53
|
the actual client like our windows
|
|
0:13:54
|
this what we are going to specify is the group user name
|
|
0:13:58
|
then we have the group key or the group
|
|
0:14:00
|
password, the pre shared key
|
|
0:14:04
|
so I know what the group name is, I know what the password is
|
|
0:14:08
|
then I have a user that is going to be for the extended authentication
|
|
0:14:12
|
so for simplicity, I will make these
|
|
0:14:14
|
username and password cisco
|
|
0:14:17
|
password for group number 1 is also cisco
|
|
0:14:21
|
then I have my pool
|
|
0:14:24
|
that is going to control whats the
|
|
0:14:26
|
ip addresses that the users are assigned
|
|
0:14:29
|
so we have a pool allocated
|
|
0:14:32
|
its called group 1 pool
|
|
0:14:35
|
where group 1 pool says
|
|
0:14:37
|
we are using the range 192.168.1.1
|
|
0:14:40
|
to 192.168.1.4
|
|
0:14:43
|
so then obviously if we wanted more than four host to be able to use the tunnel simultaneously
|
|
0:14:48
|
we would have to make the pool larger, so lets say up through
|
|
0:14:53
|
254
|
|
0:14:56
|
this is where I would also specify my access list
|
|
0:15:00
|
if I wanted to split tunneling
|
|
0:15:03
|
which in this particular I do, I want to protect the traffic, just that is going
|
|
0:15:07
|
to that 172.16
|
|
0:15:10
|
network, thats behind router3
|
|
0:15:14
|
and again remember that this access list is going to be from the perspective of the server
|
|
0:15:19
|
So on router3 we will say that the traffic is coming from
|
|
0:15:22
|
the 172.16 network
|
|
0:15:24
|
we don't necessarily know where its going
|
|
0:15:27
|
because we don't know who the initiator is of the tunnel
|
|
0:15:30
|
we will say
|
|
0:15:32
|
ip access list
|
|
0:15:35
|
extended
|
|
0:15:37
|
we will say this is the DVTI
|
|
0:15:41
|
split ACL
|
|
0:15:44
|
which is, I am going to permit ip traffic that is coming from my local networks
|
|
0:15:48
|
which is 172.16
|
|
0:15:51
|
and I don't know where its going, so it could go anywhere
|
|
0:15:56
|
then this access list DVTI split acl
|
|
0:15:59
|
this is going to be called from the client configuration group
|
|
0:16:04
|
Now I don't technically need to do this
|
|
0:16:07
|
if I were to leave this access list off
|
|
0:16:09
|
it would mean from the
|
|
0:16:10
|
test PC, its going to send all traffic from the ipsec tunnel
|
|
0:16:15
|
just depends if I want certain networks to be routed over the tunnel
|
|
0:16:18
|
and then the default routes to use the normal interface in the clear
|
|
0:16:26
|
so now we know the group username the group password
|
|
0:16:29
|
we know the ip addresses the user is going to get
|
|
0:16:32
|
we know the access list that they are going to get
|
|
0:16:35
|
next we have the isakmp profile
|
|
0:16:40
|
this again is what is going to associate the user with the particular Dynamic Interface
|
|
0:16:46
|
so we have the group name which is group number 1
|
|
0:16:48
|
that is saying that when this user comes in
|
|
0:16:51
|
we are going to authenticate them and athorize them with the local list
|
|
0:16:56
|
this is a AAA list that we are defining
|
|
0:16:59
|
says, check the local database
|
|
0:17:01
|
we could likewise send this to TACACS, we could send this to RADIUS
|
|
0:17:05
|
but the key is that, this is now on a per group basis
|
|
0:17:12
|
this here it says that the client is going to ask for an address, we are going to respond
|
|
0:17:17
|
where going to then assign them to interface virtual template 1
|
|
0:17:23
|
virtual template 1 is going to have an ipsec
|
|
0:17:25
|
profile which is the test-vti1
|
|
0:17:28
|
which is says that
|
|
0:17:31
|
we are calling this particular transform set
|
|
0:17:33
|
this particular transform set says that these are the phase II options
|
|
0:17:37
|
we are using 3DES and
|
|
0:17:39
|
SHA both with ESP
|
|
0:17:43
|
So otherwise then the only thing that we would need to change
|
|
0:17:46
|
as possibly the address of the tunnel
|
|
0:17:48
|
like lets say we are going to unnumber this to the
|
|
0:17:51
|
the loopback address of router3
|
|
0:17:54
|
it does not really matter what this address is
|
|
0:17:57
|
as long as ip is enabled on the tunnel
|
|
0:18:01
|
because just like any other interface on the router
|
|
0:18:03
|
we cannot route ip on it, unless the ip protocol is actually recommended
|
|
0:18:09
|
then the ip virtual reassembly, this is a fragmentation
|
|
0:18:13
|
feature we don't necessarily need to put that there
|
|
0:18:18
|
but in most real deployments, you would leave that on
|
|
0:18:24
|
Hey, so lets try this configuration out now
|
|
0:18:26
|
and additionally notice there is no crypto map
|
|
0:18:29
|
previously we have the crypto map
|
|
0:18:31
|
applied on the incoming interface
|
|
0:18:34
|
for the server, which is this one
|
|
0:18:37
|
but now technically router3 could accept
|
|
0:18:40
|
an easyVPN session on this interface, this interface or this one
|
|
0:18:45
|
because the virtual tunnel is listening for all traffic
|
|
0:18:49
|
that is locally destined to router3
|
|
0:18:57
|
so now lets try this out, lets go to router3
|
|
0:19:02
|
place this config in
|
|
0:19:04
|
looks like most the example is good
|
|
0:19:07
|
did generic, one message here it says that the profile is deemed incomplete until it has match identity statement
|
|
0:19:12
|
which was then the next thing that we did
|
|
0:19:16
|
so everything look good here
|
|
0:19:19
|
next lets look at the debug
|
|
0:19:21
|
crypto isakmp
|
|
0:19:25
|
it will now initiate the tunnel from the
|
|
0:19:28
|
the end host
|
|
0:19:35
|
so lets open the vpn client
|
|
0:19:39
|
we are going to start a new
|
|
0:19:42
|
a new tunnel, this is going to go to router3
|
|
0:19:45
|
and if we look at those settings again, the key point here
|
|
0:19:47
|
is the group name and the group password
|
|
0:19:51
|
this group 1, what we need to define here
|
|
0:19:54
|
as the group authentication name
|
|
0:19:58
|
password is then going to be that key if cisco
|
|
0:20:01
|
the host is going to be any address on router3
|
|
0:20:04
|
I will say its the
|
|
0:20:06
|
the link between router2 and router3
|
|
0:20:09
|
we will say, this connection entry will say R3 group 1
|
|
0:20:17
|
Now if we look at the debug on router3
|
|
0:20:20
|
as we are connecting the tunnel
|
|
0:20:22
|
as soon as we hit the connect button
|
|
0:20:25
|
if I didn't see the username and password box of your
|
|
0:20:30
|
it means what is true about the tunnel
|
|
0:20:36
|
it means that the phase I
|
|
0:20:38
|
negotiation was correct
|
|
0:20:40
|
because remember that individual username and password box, that is for extended authentication
|
|
0:20:45
|
an extended authentication doesn't occur
|
|
0:20:47
|
until phase 1.5
|
|
0:20:50
|
which means that your basic phase 1 has to work
|
|
0:20:54
|
before you get to 1.5
|
|
0:20:57
|
so if we now look at router
|
|
0:20:59
|
3 eventually what we should see that they agreed on
|
|
0:21:02
|
the
|
|
0:21:04
|
isakmp policy
|
|
0:21:06
|
where they are going to use
|
|
0:21:09
|
3DES SHA group 2
|
|
0:21:11
|
and extended authentication with
|
|
0:21:13
|
pre shared authentication for the group
|
|
0:21:16
|
the attributes are acceptable
|
|
0:21:19
|
Now phase I is complete
|
|
0:21:21
|
we are now going to move on the extended authentication
|
|
0:21:26
|
if we actually login here, lets say username cisco, password cisco
|
|
0:21:34
|
we should now see the mode configuration attributes
|
|
0:21:39
|
says we are assigning the address 192.168.1.1
|
|
0:21:43
|
then we are sending them the access list DVTI_SPLIT_ACL
|
|
0:21:52
|
then once phase 1.5 is complete
|
|
0:21:55
|
we see they
|
|
0:21:57
|
started negotiating the actual ipsec
|
|
0:21:59
|
transform set
|
|
0:22:01
|
So now phase I is completely done
|
|
0:22:05
|
eventually they agreed that we are going to use
|
|
0:22:07
|
ESP 3DES with
|
|
0:22:10
|
HMAC SHA
|
|
0:22:12
|
we are running in tunnel mode
|
|
0:22:13
|
this is the particular security association lifetime
|
|
0:22:18
|
if we now look at the show crypto isakmp sa
|
|
0:22:23
|
we should see the phase I tunnel is complete
|
|
0:22:25
|
the state is QM_IDLE
|
|
0:22:27
|
or quick mode idle
|
|
0:22:28
|
which means that we are now moving on to phase II
|
|
0:22:33
|
Now notice additionally here it says that this is for vpn1-ra
|
|
0:22:38
|
and if we show run
|
|
0:22:41
|
include vpn1-ra
|
|
0:22:44
|
that is the name of the isakmp profile
|
|
0:22:48
|
so it means that this individual phase I tunnel landed on that profile
|
|
0:22:52
|
and that was based on the group address
|
|
0:22:55
|
or the group name, I should say
|
|
0:22:58
|
we now look at the show cypto ipsec sa
|
|
0:23:03
|
says the interface we are using is now virtual template II
|
|
0:23:06
|
or virtual access II
|
|
0:23:08
|
which is an instance of virtual template II
|
|
0:23:11
|
the security association is going towards 192.168.118.100
|
|
0:23:18
|
specifically for this address, this is what we assign to them
|
|
0:23:25
|
Now right now, since we are not going through Network Address Translation
|
|
0:23:29
|
we have not offered them NAT reversal or NAT transparency
|
|
0:23:33
|
which means that this is going to be natively encapsulated inside of ESP
|
|
0:23:39
|
which again would then assume that from the test pc
|
|
0:23:42
|
that we have proper ESP transport to the server
|
|
0:23:45
|
and from the server back
|
|
0:23:49
|
in this particular case on the ASA
|
|
0:23:52
|
the way that I am allowing this, if you look at the
|
|
0:23:55
|
show run policy map
|
|
0:23:58
|
is by inspecting
|
|
0:24:01
|
the ESP traffic is this going through
|
|
0:24:05
|
again the other alternatives to this would be to manually allow the ESP in
|
|
0:24:10
|
I could configure Network Address Translation on the ASA
|
|
0:24:14
|
which is then going to force the IOS's VPN server
|
|
0:24:18
|
to offer the client NAT transparency with NAT reversal
|
|
0:24:21
|
or I can configure it to tunnel it over tcp
|
|
0:24:27
|
so it really doesn't matter which option I use
|
|
0:24:31
|
and if we now go back to the Windows machine
|
|
0:24:34
|
if we look at the routing table
|
|
0:24:37
|
we could say in the route frame from the command line
|
|
0:24:39
|
or we could go to
|
|
0:24:41
|
the VPN client and look at the
|
|
0:24:43
|
statistics
|
|
0:24:46
|
the route details, this is going to be the split tunnelling access list
|
|
0:24:51
|
under the tunnel details it says that
|
|
0:24:55
|
we have this particular crypto maps, so its 3DES
|
|
0:24:59
|
SHA
|
|
0:25:00
|
transparent tunnelling is off
|
|
0:25:02
|
it is inactive, so we are running natively over ESP
|
|
0:25:09
|
So now lets actually send traffic out of the tunnel and see if this
|
|
0:25:12
|
encryption and decryption
|
|
0:25:14
|
is going to increment
|
|
0:25:16
|
lets ping 172.16.4.4
|
|
0:25:25
|
Says the traffic is getting encrypted
|
|
0:25:29
|
traffic is getting encrypted but
|
|
0:25:32
|
here we go, now its coming back in
|
|
0:25:34
|
So this portion here, this was most likely just convergence
|
|
0:25:38
|
of the
|
|
0:25:40
|
the tunnel on the server's end
|
|
0:25:42
|
If I were now to telnet
|
|
0:25:44
|
to that address, lets telnet to router4
|
|
0:25:48
|
if we log in
|
|
0:25:51
|
then look at the show users
|
|
0:25:54
|
we should see this coming from the
|
|
0:25:59
|
post network address, translation address
|
|
0:26:03
|
So this is the one that is assigned to the tunnel interface
|
|
0:26:07
|
and we could see this Astrix, this is our active session here, so ignore this one
|
|
0:26:13
|
Now if I were to telnet to someone that is outside the tunnel
|
|
0:26:18
|
lets say, I telnet to
|
|
0:26:20
|
router2 for example
|
|
0:26:25
|
and show users
|
|
0:26:28
|
the address now is my original address
|
|
0:26:32
|
it means that this traffic is now not being sent out of the tunnel
|
|
0:26:36
|
because the split tunnel acl says that I would not use the tunnel to get to
|
|
0:26:41
|
200.0.0.2
|
|
0:26:43
|
I am only using it to get to
|
|
0:26:46
|
devices that are in 172.16 network
|
|
0:26:52
|
So we could see here from the VPN client's perspective
|
|
0:26:56
|
there is no change
|
|
0:26:57
|
it doesn't know whether we are using the virtual tunnel interface
|
|
0:27:02
|
on the head end
|
|
0:27:03
|
or whether we are using the dynamic crypto maps
|
|
0:27:08
|
on router3, if we look at the routing table
|
|
0:27:11
|
automatically when the client connects
|
|
0:27:14
|
there is going to be a static route
|
|
0:27:16
|
for that particular host
|
|
0:27:18
|
on that individual virtual access
|
|
0:27:23
|
Now if we were to have an additional client
|
|
0:27:27
|
lets say we were to go to router5
|
|
0:27:31
|
and we are going to configure router5 with the software client
|
|
0:27:35
|
where this is our outside interface, this is the inside interface
|
|
0:27:39
|
and we want all traffic thats going this way
|
|
0:27:42
|
to be translated to some address that router 3 is assigning
|
|
0:27:47
|
So same configuration logic as we did before
|
|
0:27:50
|
again the only thing that we need to do here
|
|
0:27:53
|
is to find the group username and password
|
|
0:27:57
|
to find the peer address and then apply the
|
|
0:28:00
|
the client to the interface
|
|
0:28:02
|
So we will say crypto ipsec client
|
|
0:28:05
|
its an easy VPN client config
|
|
0:28:09
|
this name here, it could be whatever, we will say easyVPN
|
|
0:28:13
|
client name
|
|
0:28:16
|
what is important is what is the group username
|
|
0:28:19
|
so the group that router3 is listening for is group 1
|
|
0:28:24
|
with the key of cisco
|
|
0:28:26
|
the peers address is 200.0.23.3
|
|
0:28:32
|
and the mode that we are going to use is client
|
|
0:28:35
|
we could use network extension or we could use network plus
|
|
0:28:38
|
and result is going to be the same from the
|
|
0:28:41
|
the previous configuration examples we did
|
|
0:28:46
|
so now on the interfaces we have on fastethernet0/1
|
|
0:28:50
|
this is our outside
|
|
0:28:52
|
fastethernet0/0 is the inside
|
|
0:28:55
|
So it will say crypto ipsec client
|
|
0:28:58
|
easyvpn and then the name of the config
|
|
0:29:02
|
so vpn client name
|
|
0:29:06
|
this is the outside
|
|
0:29:08
|
fastethernet0/0 is the inside
|
|
0:29:15
|
Now if the tunnel is working properly
|
|
0:29:17
|
we should get this
|
|
0:29:19
|
log message that we need to do extended authentication
|
|
0:29:23
|
username cisco, password cisco
|
|
0:29:29
|
we can see from router3's debug of crypto isakmp
|
|
0:29:32
|
we are going through another phase I negotiation
|
|
0:29:35
|
we should see that there is a new address that is assigned to the tunnel
|
|
0:29:40
|
and on router5, this is assigned to its loopback
|
|
0:29:43
|
so if we show ip interface brief
|
|
0:29:46
|
we could see its part for the VPN pool, I was assigned the 192.168.1.2 address
|
|
0:29:54
|
on router3, if we look at the routing table
|
|
0:30:00
|
we should see two separate entries now, one that is for
|
|
0:30:04
|
the windows machine, the test pc
|
|
0:30:07
|
and then one that is for router5
|
|
0:30:12
|
Now the key point about this functional difference of using the Dynamic Virtual Tunnel Interfaces versus the crypto maps
|
|
0:30:19
|
is that I can now easily classify
|
|
0:30:21
|
traffic that is going to the windows machine
|
|
0:30:25
|
versus the traffic that is going to router5
|
|
0:30:28
|
because they are two separate interfaces
|
|
0:30:31
|
essentially that were using, one is for virtual access 1 , one is for virtual access
|
|
0:30:35
|
3, virtual access 2 and virtual access 3
|
|
0:30:42
|
Now I could be take this one step further
|
|
0:30:44
|
and say that based on the group
|
|
0:30:47
|
authentication
|
|
0:30:48
|
which again is going to be controlled by now the isakmp
|
|
0:30:52
|
profile
|
|
0:30:54
|
if we show run section crypto
|
|
0:30:57
|
we could define a new
|
|
0:31:00
|
isakmp profile
|
|
0:31:02
|
that says we look for a different group address
|
|
0:31:06
|
lets say that we are going to use group 2
|
|
0:31:11
|
where we will take this previous configurations, its going to be similar
|
|
0:31:15
|
but we are going to change it around a little bit, so there is a separate
|
|
0:31:18
|
virtual tunnel interface
|
|
0:31:22
|
so we will have a new
|
|
0:31:24
|
configuration group, we will say this is group 2
|
|
0:31:28
|
all of the other configuration is going to be same there
|
|
0:31:31
|
but for profile vpn2ra
|
|
0:31:35
|
we will say its group number2
|
|
0:31:37
|
we are going to assign them to interface virtual template 2
|
|
0:31:42
|
this would then mean that we have a new interface if we show run interface virtual
|
|
0:31:47
|
template 1
|
|
0:31:52
|
means I have a new
|
|
0:31:54
|
interface here
|
|
0:31:56
|
I could still use the saem crypto profile
|
|
0:31:59
|
if I didn't want to change the transform set
|
|
0:32:02
|
but now its allowing me to categorize
|
|
0:32:06
|
users that authenticate with group2
|
|
0:32:08
|
separately than users that authenticate with group 1
|
|
0:32:13
|
So now lets say for example that if someone authenticates with group number 2
|
|
0:32:17
|
I want to put some restrictions on what type of traffic they can send in to the network
|
|
0:32:22
|
where may be
|
|
0:32:23
|
I want to allow them to
|
|
0:32:25
|
to run everything except the icmp pings
|
|
0:32:29
|
where we could say access list
|
|
0:32:33
|
IP access list extended
|
|
0:32:36
|
we will say VPN to
|
|
0:32:41
|
VPN to filter
|
|
0:32:43
|
that says deny ICMP traffic
|
|
0:32:46
|
but permit anything else
|
|
0:32:49
|
Now for the application of this, since we have an interface that is associated with the tunnel
|
|
0:32:53
|
there is nothing else thats special, other than saying ip access group
|
|
0:32:57
|
vpn2-filter in
|
|
0:33:00
|
or access group vpn2-filter out
|
|
0:33:05
|
but now the functional difference of this
|
|
0:33:08
|
is depended on how the user authenticates
|
|
0:33:15
|
so depending on the group user name and password
|
|
0:33:18
|
its going to either assign them to interface
|
|
0:33:22
|
virtual template 1
|
|
0:33:24
|
or virtual template 2
|
|
0:33:29
|
if we were to look at the other options of the crypto profile
|
|
0:33:33
|
lets say show run section crypto
|
|
0:33:39
|
crypto isakmp
|
|
0:33:43
|
we have two different profiles, one for
|
|
0:33:47
|
group 2, one of them for group 1
|
|
0:33:54
|
some of the other options we could change here
|
|
0:33:57
|
would be the QoS identifier
|
|
0:34:00
|
so we can classify with an internal marking
|
|
0:34:04
|
whats the difference between group 1 users versus the group 2
|
|
0:34:07
|
then I could say may be
|
|
0:34:08
|
based on how someone else is authenticating
|
|
0:34:11
|
I am going to give them
|
|
0:34:12
|
a different bandwidth limitation
|
|
0:34:15
|
or I am going to give them
|
|
0:34:16
|
low latency for their Voice Over IP traffic
|
|
0:34:21
|
I could also say based on their group name
|
|
0:34:23
|
I am going to use a different certificate authority
|
|
0:34:27
|
So I could say that
|
|
0:34:28
|
may be I have two different CA servers
|
|
0:34:31
|
if you authenticate with group number 1
|
|
0:34:34
|
then you are going to get CA server 1
|
|
0:34:36
|
but if you authenticate with group number 2, you are going to get a different one
|
|
0:34:41
|
so lets try this out now, if we were to go back to the
|
|
0:34:44
|
the windows machine
|
|
0:34:46
|
and we could see right now off we are authenticated to group number 1
|
|
0:34:51
|
I should be able to ping router4, no problem
|
|
0:34:54
|
because we are not filtering anything out
|
|
0:34:58
|
if I disconnect
|
|
0:35:02
|
we could see the traffic is still allowed
|
|
0:35:05
|
the difference now if I were to go to router4
|
|
0:35:08
|
and lets look at the debug ip icmp
|
|
0:35:14
|
when the tunnel is not configured
|
|
0:35:16
|
or when the tunnel is not active
|
|
0:35:18
|
these pings are coming from
|
|
0:35:20
|
the normal address of the test pc
|
|
0:35:23
|
the 192.168.118.100
|
|
0:35:28
|
once the tunnel comes up
|
|
0:35:31
|
so lets reconnect the tunnel again
|
|
0:35:40
|
we should see the destination is going to change, so now its the tunnel address
|
|
0:35:46
|
and if we were to authenticate again
|
|
0:35:50
|
but now we are going to do this to a different group, so lets disconnect this one
|
|
0:35:55
|
I will make a copy of this
|
|
0:35:57
|
lets duplicate the session
|
|
0:36:00
|
but we are going to modify it, so it has different group name
|
|
0:36:07
|
we will say this is router3, group2
|
|
0:36:20
|
and we could see, now the new filter is being applied
|
|
0:36:24
|
where router3 is dropping the packets
|
|
0:36:27
|
is then responding back with an icmp unreachable
|
|
0:36:33
|
its then replying back with a icmp unreachable, which is the administratively prohibited
|
|
0:36:40
|
if we were to now go to router3
|
|
0:36:44
|
and look at the
|
|
0:36:46
|
show crypto isakmp
|
|
0:36:49
|
sa
|
|
0:36:58
|
we can see, we have the phase I tunnel which is fine
|
|
0:37:02
|
if we show the
|
|
0:37:04
|
crypto ipsec sa
|
|
0:37:07
|
says that this host which is
|
|
0:37:11
|
and lets actually see, which one it is, if we go to the
|
|
0:37:13
|
the windows machine, lets look at the ip config
|
|
0:37:18
|
this end point of the tunnel is 192.168.1.4
|
|
0:37:25
|
on router3, if we look at the
|
|
0:37:27
|
particular ipsec sa for that address, the 1.4
|
|
0:37:33
|
says this is using Interface Virtual access to
|
|
0:37:38
|
we see that the particular transform set thats assigned
|
|
0:37:41
|
but I could technically different way, if I wanted
|
|
0:37:44
|
because I have different
|
|
0:37:46
|
virtual templates, which means I have different crypto
|
|
0:37:49
|
ipsec profiles
|
|
0:37:51
|
we show run interface virtual
|
|
0:37:54
|
template 1 versus template 2
|
|
0:37:58
|
again the assignment between them is based on the
|
|
0:38:01
|
isakmp profile
|
|
0:38:04
|
now the other variation of this configuration would be on the
|
|
0:38:07
|
ipsec client
|
|
0:38:10
|
which is router5
|
|
0:38:12
|
we could change its
|
|
0:38:15
|
easyVPN client configuration
|
|
0:38:17
|
So that is also referencing a virtual template
|
|
0:38:20
|
this would then allow us to do, different QoS parameters, different filtering parameters
|
|
0:38:24
|
based on the particular tunnel that they are assigned to
|
|
0:38:29
|
so again the goal of using the dynamic virtual templates
|
|
0:38:32
|
or virtual tunnel interfaces
|
|
0:38:35
|
is that we have an interface
|
|
0:38:37
|
associated with ipsec tunnel
|
|
0:38:39
|
without having to add the additional overhead of GRE
|
|
0:38:42
|
or to run some more complicated design like DMVPN
|
|
0:38:46
|
for multipoint GRE tunnels
|
|
0:38:50
|
so next lets look at our current configurations on router5
|
|
0:38:54
|
if we look at the show run section crypto
|
|
0:38:58
|
we have the ipsec client configuration
|
|
0:39:01
|
where we are specifying the group name, we are specifying the group key
|
|
0:39:05
|
the peer
|
|
0:39:06
|
then we have the actual client applied on the interfaces
|
|
0:39:10
|
where we have the fastethernet0/1
|
|
0:39:13
|
applied as the outside interface and then fastethernet0/0
|
|
0:39:17
|
which is going to router6 that is the inside interface
|
|
0:39:24
|
Now for the Dynamic Virtual Tunnel Interface Variation of this
|
|
0:39:28
|
its only a minor change from what we see as the current configuration
|
|
0:39:32
|
but we are going to specify what is the particular virtual
|
|
0:39:36
|
template interface
|
|
0:39:37
|
that we want for the client configurtion
|
|
0:39:40
|
So before I make this change
|
|
0:39:42
|
first thing that I want to do is to remove the
|
|
0:39:44
|
previous client configuration from the interface
|
|
0:39:47
|
to make sure that we don't run into any type of order of operations problems
|
|
0:39:53
|
so on fastethernet0/0, we will remove the inside
|
|
0:39:57
|
interface
|
|
0:39:59
|
on fastethernet0/0
|
|
0:40:01
|
0/1 will remove the outside interface
|
|
0:40:05
|
we now look at the show run section crypto
|
|
0:40:12
|
we have the client configuration, and actually its still on the inside interface, lets remove that
|
|
0:40:17
|
but notice the log messge it says that
|
|
0:40:19
|
that the loopback interface change to down
|
|
0:40:22
|
this was because the tunnel was previously working
|
|
0:40:25
|
then since we removed the configuration, it had to disconnect
|
|
0:40:28
|
the ipsec sa
|
|
0:40:30
|
So our next step on router5 is we are going to configure the new virtual template interface
|
|
0:40:36
|
that were going to use the dynamic virtual
|
|
0:40:38
|
tunnel interface or the DVTI
|
|
0:40:40
|
we will say that this is interface virtual template
|
|
0:40:44
|
1, giving any arbitrary number
|
|
0:40:47
|
but the key is that this is a special type that is for tunneling
|
|
0:40:52
|
then just like on the server we need to make sure that we have an ip address
|
|
0:40:56
|
and doesn't necessarily matter what it is
|
|
0:40:58
|
as long as ip enabled
|
|
0:41:00
|
so we could put a new
|
|
0:41:03
|
primary address, we could put
|
|
0:41:05
|
an unnumbered address, we will say unnumbered to the loopback
|
|
0:41:08
|
as long as ip is running there
|
|
0:41:11
|
then additionally under the
|
|
0:41:13
|
client configuration
|
|
0:41:16
|
here we are going to specify that this configuration is then tied
|
|
0:41:20
|
to that virtual interface
|
|
0:41:22
|
or that is the virtual template number
|
|
0:41:26
|
then we need to reapply this configuration on the physical interfaces
|
|
0:41:31
|
So on fastethernet
|
|
0:41:35
|
0/0 and fastethernet0/1
|
|
0:41:39
|
so this is now the, again the inside interface
|
|
0:41:43
|
fa0/1 is the outside interface
|
|
0:41:48
|
next lets look at the debug crypto ipsec
|
|
0:41:52
|
client for easyVPN
|
|
0:41:55
|
and we should be able to see
|
|
0:41:57
|
router5 attempting to connect the session
|
|
0:42:01
|
if we look at show crypto isakmp sa
|
|
0:42:04
|
we don't have any phase I negotiation
|
|
0:42:06
|
So now lets attempt to send traffic out the interfaces
|
|
0:42:11
|
from router4
|
|
0:42:12
|
or router6, I should say, lets
|
|
0:42:15
|
send traffic to router4
|
|
0:42:17
|
to 172.16.4.4
|
|
0:42:22
|
and ideally we should see the debug on router5
|
|
0:42:27
|
Now since I don't see the phase I tunnel trying to negotiate
|
|
0:42:31
|
most likely what this means
|
|
0:42:33
|
is that either the
|
|
0:42:35
|
the interesting traffic is not triggering the tunnel
|
|
0:42:39
|
may be I don't have the tunnel properly apply to the interfaces
|
|
0:42:43
|
or that router3 is not actually listening
|
|
0:42:45
|
for the connection
|
|
0:42:50
|
Now we do already know that router3 is listening for the connection
|
|
0:42:53
|
because both the windows vpn client was working before
|
|
0:42:57
|
and router5 was running the normal
|
|
0:43:00
|
easyVPN remote, the original software client
|
|
0:43:06
|
so now lets double check on
|
|
0:43:08
|
router5 that this is properly applied, lets look at the show crypto
|
|
0:43:11
|
ipsec client
|
|
0:43:15
|
easyVPN, it says that
|
|
0:43:17
|
the inside interface is fastethernet0/0
|
|
0:43:21
|
outside interface is fastethernet 0/1
|
|
0:43:24
|
the current easyVPN peer
|
|
0:43:26
|
is 200.0.23.3 which is what we want
|
|
0:43:29
|
if we look at the show ip interface brief
|
|
0:43:33
|
ideally what we should see
|
|
0:43:35
|
is that there is going to be
|
|
0:43:37
|
an ip address that is assigned to the virtual access
|
|
0:43:43
|
Now you may find that this configuration is a little bit more sensitive to the order of operations
|
|
0:43:48
|
than the
|
|
0:43:49
|
the previous one, when we were not using virtual tunnels
|
|
0:43:54
|
So lets look at this one more
|
|
0:43:56
|
time, I may need to remove
|
|
0:43:59
|
the configuration and then reapply it
|
|
0:44:05
|
but lets try to clear, lets say
|
|
0:44:07
|
clear crypto ipsec
|
|
0:44:10
|
client easyVPN
|
|
0:44:20
|
then try to initiate traffic, lets ping 172.16.4.4
|
|
0:44:30
|
still not no debug output
|
|
0:44:31
|
we could try to manually initiate the tunnel
|
|
0:44:34
|
with the crypto
|
|
0:44:36
|
crypto ipsec client
|
|
0:44:39
|
easyVPN connect command
|
|
0:44:45
|
but it says the user connect
|
|
0:44:47
|
request is ignored
|
|
0:44:49
|
because the tunnel end point is not ready for a request
|
|
0:44:56
|
So lets see what else we could possibly be missing in the config, lets say show run
|
|
0:45:00
|
section crypto or
|
|
0:45:03
|
interface
|
|
0:45:07
|
we have the group name, we have the group password
|
|
0:45:10
|
we are running in client mode
|
|
0:45:12
|
we have the peer address defined
|
|
0:45:14
|
we have the virtual interface defined
|
|
0:45:18
|
the virtual interface should be of type tunnel which it is
|
|
0:45:22
|
then we have
|
|
0:45:24
|
the client configured on the outside interface and the inside interface
|
|
0:45:29
|
so it looks like the configuration should be solid
|
|
0:45:33
|
what I am going to do now, just to make sure its
|
|
0:45:37
|
either a configuration problem or unrelated to configuration
|
|
0:45:40
|
is to save router5's configuration and then reload
|
|
0:47:33
|
so now we could see router5 has been reloaded
|
|
0:47:36
|
and notice one of the first log messages that comes up here
|
|
0:47:39
|
it says that, there is now pending extended authentication request
|
|
0:47:43
|
and we need to send our usename and password
|
|
0:47:47
|
so the key point of this demo here
|
|
0:47:50
|
is that you need to make sure that you do include reloading
|
|
0:47:55
|
as part of your troubleshooting process
|
|
0:47:57
|
especially when some of this configurations
|
|
0:47:59
|
you are making a lot of changes
|
|
0:48:00
|
adding new stuff, removing old stuff
|
|
0:48:03
|
sometimes the ipsec process would get hung
|
|
0:48:05
|
where if removing the crypto map of the interface and reapplying it doesn't work
|
|
0:48:10
|
then was last ditch effort you can reload
|
|
0:48:12
|
move onto something else
|
|
0:48:14
|
comeback later and see if that has changed
|
|
0:48:16
|
the problem at all
|
|
0:48:18
|
Now what we should see is the final result of this, if we look at the show ip interface brief
|
|
0:48:23
|
that the address that is allocated from the vpn server
|
|
0:48:26
|
should be assigned to a virtual access
|
|
0:48:30
|
and this is now the actual logical instance
|
|
0:48:33
|
of the dynamic virtual tunnel interface
|
|
0:48:38
|
also if we look at the routing table
|
|
0:48:40
|
we should see the split tunnel acl
|
|
0:48:43
|
installed as a static route
|
|
0:48:45
|
via the virtual interface
|
|
0:48:49
|
so now router3, who is the server, is dynamically advertising
|
|
0:48:53
|
172.16.0.0/16 to us
|
|
0:48:58
|
and if we try to send traffic
|
|
0:49:00
|
to any of these destinations
|
|
0:49:03
|
we could see it is working
|
|
0:49:04
|
if we were to telnet there
|
|
0:49:08
|
then look at the show users
|
|
0:49:11
|
router4 is saying that 5's connection is coming from inside of the ipsec tunnel
|
