|
0:00:13
|
In our next section we are going to look at running the easy VPN server on the IOS routers
|
|
0:00:19
|
which again the first thing that we would want to know
|
|
0:00:21
|
is where is this located
|
|
0:00:23
|
from the documentation in the configuration guides
|
|
0:00:28
|
we will see that there is a lot of individual steps that we need to go through
|
|
0:00:31
|
in order to implement this particular configuration
|
|
0:00:34
|
and there is multiple different variation whether we are using the Dynamic crypto map
|
|
0:00:39
|
or whether we are using the Dynamic Virtual Tunnel Interfaces or the DVTIs
|
|
0:00:46
|
in either case both of these are going to be under products
|
|
0:00:50
|
IOS, regular IOS
|
|
0:00:53
|
12.4, 12.4T
|
|
0:00:56
|
configuration guides
|
|
0:00:58
|
then under security we have secure connectivity
|
|
0:01:05
|
then we have easy vpn
|
|
0:01:08
|
two portions of documentation, the easy VPN remote, this is the
|
|
0:01:11
|
client configuration
|
|
0:01:14
|
then the easy VPN server
|
|
0:01:16
|
obviously is going to be the server configuration
|
|
0:01:21
|
Now when you look at this documentation, there is generally two portions that you would want to
|
|
0:01:26
|
to go through
|
|
0:01:28
|
the one is how to configure the easy VPN server
|
|
0:01:32
|
which is going to give us the step by step task list
|
|
0:01:35
|
of what is required
|
|
0:01:37
|
and what is optional
|
|
0:01:39
|
where mainly we can see it says we need to configure AAA in order to do our policy lookup
|
|
0:01:44
|
we need to configure the mode configuration and extended authentication options
|
|
0:01:51
|
we need to define the group policy information
|
|
0:01:53
|
for the mode configuration push
|
|
0:01:57
|
So this is going to be the
|
|
0:01:58
|
the per group authentication
|
|
0:02:04
|
then the vast majority of these other particular options
|
|
0:02:08
|
we don't necessarily have to configure them but we can
|
|
0:02:12
|
so this would be one way that we can piece the configuration together
|
|
0:02:15
|
is to go through the individual task list and look at what is required what is optional
|
|
0:02:19
|
and look at the possible configurations
|
|
0:02:21
|
the other way would be to go towards the end
|
|
0:02:24
|
and go to the configuration examples
|
|
0:02:28
|
we will see both for the IOS and the ASA
|
|
0:02:31
|
generally this is one of the best way to piece the configuration together
|
|
0:02:35
|
just copy the example we have here
|
|
0:02:37
|
and then we can change it around to match the particular
|
|
0:02:41
|
configuration design that we need
|
|
0:02:45
|
So lets take this input this in to notepad
|
|
0:02:50
|
we will see that a lot of these configuration is similar to
|
|
0:02:53
|
previous lan to lan vpn
|
|
0:02:56
|
configurations that we did
|
|
0:02:58
|
where we have the same type of configuration
|
|
0:03:00
|
for the isakmp policy
|
|
0:03:03
|
where we have our authentication, we have our hash
|
|
0:03:06
|
the Diffy Halman group
|
|
0:03:08
|
the encryption
|
|
0:03:11
|
and you do have to be careful with this, because depending up on the individual client or version
|
|
0:03:17
|
some of them will support different types of Diffy Halman groups
|
|
0:03:21
|
or different types of authentication
|
|
0:03:23
|
or some of the older ones may not support group 5
|
|
0:03:26
|
some of the older ones may not support AES
|
|
0:03:29
|
and likewise you may see that some of them do not support group 1
|
|
0:03:33
|
for the Diffy Halman exchange
|
|
0:03:36
|
Now when we actually configure this and then go through the debug
|
|
0:03:39
|
of debug crypto isakmp on the server
|
|
0:03:42
|
one thing we will see that is different
|
|
0:03:44
|
when we are using the easy VPN server and the client
|
|
0:03:48
|
is that they are going to be running in aggressive mode
|
|
0:03:52
|
as opposed to main mode
|
|
0:03:54
|
for phase I negotiation
|
|
0:03:56
|
which means that we are essentially going to offer
|
|
0:03:59
|
all these different possible policies
|
|
0:04:01
|
from the client to the server
|
|
0:04:04
|
then the server is going to respond with which particular policy
|
|
0:04:06
|
that is acceptable
|
|
0:04:09
|
So when we look at the debug output, we will see that its generally much more
|
|
0:04:13
|
output to see when we are looking at the easy VPN server and client
|
|
0:04:17
|
versus the lan to lan tunnel
|
|
0:04:20
|
So would be a good idea if you are going to debug this
|
|
0:04:23
|
you probably want to send this to the buffer as opposed to sending this to the console
|
|
0:04:30
|
So lets start to build this configuration
|
|
0:04:32
|
based on the example and the documentation
|
|
0:04:35
|
we know that one of the first things that we need is going to be the isakmp policy
|
|
0:04:40
|
So we will say that this is isakmp
|
|
0:04:42
|
policy 10
|
|
0:04:44
|
we will use the md5 hash, we will use pre shared authentication
|
|
0:04:48
|
we will use group number 2
|
|
0:04:51
|
and we will say the encryption
|
|
0:04:53
|
is going to be 3DES
|
|
0:04:58
|
since we are now using pre shared authentication
|
|
0:05:02
|
it then means that we need to define what is the username and password for phase I
|
|
0:05:09
|
in the case of the vpn client configuration
|
|
0:05:12
|
the phase I authentication is the group
|
|
0:05:15
|
authentication
|
|
0:05:17
|
and this is what the crypto isakmp
|
|
0:05:19
|
client configuration group does
|
|
0:05:23
|
the name of this group here
|
|
0:05:26
|
is the value
|
|
0:05:27
|
that we are going to be putting in the VPN client side
|
|
0:05:32
|
So on the test pc, this is what goes under the group
|
|
0:05:35
|
username and the group authentication
|
|
0:05:39
|
So I will say that this is the easy VPN
|
|
0:05:43
|
_group
|
|
0:05:45
|
and the key or the password is going to be cisco
|
|
0:05:50
|
we are going to additionally see some of the other options here like
|
|
0:05:52
|
the DNS server the WIN server, the domain name
|
|
0:05:57
|
these are not going to be required options
|
|
0:05:59
|
we could put them in there, but we don't necessarily have to
|
|
0:06:02
|
Now the once that I do want to have in there
|
|
0:06:05
|
would be this pool
|
|
0:06:08
|
which I will say, this is the easy-vpn_pool
|
|
0:06:13
|
this is going to define what is the ip address that the client is issued
|
|
0:06:18
|
once the phase 1.5 negotiation
|
|
0:06:21
|
through remote configuration and extended authentication has completed
|
|
0:06:25
|
so the pool is being called from client configuration group
|
|
0:06:28
|
then towards the end we should see that the pool is defined
|
|
0:06:34
|
where they have ip local pool
|
|
0:06:36
|
I will say this is the
|
|
0:06:38
|
easyVPN_pool
|
|
0:06:41
|
and the particular subnet that
|
|
0:06:43
|
I want to define
|
|
0:06:49
|
we will specify as 172.16.255.0/24
|
|
0:06:59
|
So once the VPN client attaches
|
|
0:07:02
|
router3 to vpn server is then going to allocate it an address from its particular pool
|
|
0:07:08
|
So we will change this pool around to say that
|
|
0:07:10
|
it will be the 172.16.255.1
|
|
0:07:15
|
through 172.16.255.254
|
|
0:07:21
|
and lets move this up towards the
|
|
0:07:24
|
the client configuration groups that we can see exactly where this fits in
|
|
0:07:30
|
So we have the pool there
|
|
0:07:32
|
the access list is going to define the split tunneling policy
|
|
0:07:37
|
which controls what traffic should go over the VPN
|
|
0:07:40
|
and which traffic should be sent in the clear
|
|
0:07:44
|
if I do not define the access list here
|
|
0:07:47
|
then all traffic
|
|
0:07:48
|
that the VPN traffic sends is automatically going to be sent over the tunnel
|
|
0:07:54
|
Now this configuration can get a little bit confusing
|
|
0:07:58
|
for the access list logic
|
|
0:08:00
|
but the point to remember here is that the access list is from the perspective of the server
|
|
0:08:05
|
not from the perspective of the client
|
|
0:08:09
|
So lets say for this particular design that once the test pc connects
|
|
0:08:13
|
I wanted to send over the tunnel
|
|
0:08:16
|
only traffic that is going to 172.16.34
|
|
0:08:21
|
and 172.16.4.0/24
|
|
0:08:26
|
this means that in the split tunneling acl
|
|
0:08:30
|
from router3's perspective who again is the server
|
|
0:08:36
|
this is going to be traffic that is coming from the ip source
|
|
0:08:40
|
172.16.34.0
|
|
0:08:45
|
going to anywhere
|
|
0:08:48
|
and likewise from 172.16.4.0
|
|
0:08:52
|
going to anywhere
|
|
0:08:57
|
this means that from the access list syntax
|
|
0:08:59
|
where I am specifying acl 199 here
|
|
0:09:02
|
I want to say that this is going to be traffic that is coming from
|
|
0:09:07
|
172.16.34.0
|
|
0:09:10
|
and 172.16.4.0
|
|
0:09:17
|
So its the source not the destination
|
|
0:09:20
|
I could be a little bit less specific here
|
|
0:09:23
|
I could say that the
|
|
0:09:27
|
acl is going to be anything that start with 172.16
|
|
0:09:31
|
what this will ultimately control
|
|
0:09:33
|
is what are the static routes
|
|
0:09:36
|
that are assigned to the vpn client
|
|
0:09:40
|
So once the vpn client connects, then we go to the command line and look at the route print output
|
|
0:09:45
|
we should see that its going to have two new static routes installed
|
|
0:09:49
|
one to 172.16.34.0/24
|
|
0:09:53
|
and one for 172.16.4.0/24
|
|
0:10:04
|
okay, so now we have the address pool, thats going to be assigned
|
|
0:10:08
|
we have the access list that specifies what type of traffic is going to go over the tunnel
|
|
0:10:15
|
next thing we need to figure out how are we actually going to authenticate the individual user
|
|
0:10:21
|
with the extended authentication
|
|
0:10:23
|
we can either do this locally
|
|
0:10:26
|
or we could do this via RADIUS or TACACS through AAA
|
|
0:10:31
|
for this particular example we are going to do it locally
|
|
0:10:34
|
we will come back later in our
|
|
0:10:36
|
identity management sections and talk about how to send this to RADIUS
|
|
0:10:40
|
and also how to get this individual attributes to RADIUS
|
|
0:10:44
|
like in address pool based on the username and password
|
|
0:10:48
|
or a split tunneling acl based on the extended authentication
|
|
0:10:55
|
so if we look at the RADIUS configuration or the AAA configuration, I should say
|
|
0:11:00
|
we have AAA enabled
|
|
0:11:02
|
a type of authentication and a type of authorization
|
|
0:11:07
|
where login authentication is
|
|
0:11:09
|
just like we would have if we were trying to telnet into the router or trying to ssh into the route
|
|
0:11:15
|
but network authorization
|
|
0:11:17
|
this one is going to be specifically
|
|
0:11:19
|
for the easy VPN client configuration
|
|
0:11:23
|
So similar to if you were to have, like a ppp dialup configuration
|
|
0:11:27
|
that would be network authorization
|
|
0:11:31
|
I am going to say that these are called
|
|
0:11:34
|
lets call this easyVPN
|
|
0:11:37
|
easyVPN_AAA
|
|
0:11:40
|
and we will say these go to the local Database
|
|
0:11:46
|
easyvpn_aaa
|
|
0:11:51
|
Now since I am using the local database, this is then going to imply
|
|
0:11:54
|
that I need a username and password, so we will say username cisco
|
|
0:11:58
|
password cisco
|
|
0:12:04
|
next we have the
|
|
0:12:06
|
crypto transform set, this is going to be our phase II options
|
|
0:12:10
|
I will say here
|
|
0:12:12
|
we can use what they have listed, it says DES and SHA
|
|
0:12:16
|
this is then called from a Dynamic crypto map
|
|
0:12:21
|
that is setting this transform set
|
|
0:12:24
|
and lets put this in capitals, just to make it a little bit easier to read
|
|
0:12:31
|
so the dynamic crypto map is named mode
|
|
0:12:34
|
and its using sequence number one
|
|
0:12:36
|
lets make this a little bit clear, lets say that this is the dynamic _map
|
|
0:12:41
|
sequence number 1
|
|
0:12:43
|
where then the dynamic map
|
|
0:12:46
|
is going to called from the static crypto map
|
|
0:12:51
|
So in their example, they are not really making it that
|
|
0:12:53
|
clear here, because the dynamic map and the static map were named the same thing
|
|
0:12:57
|
both of them were named mode
|
|
0:13:01
|
So to make this a little bit easier to read, we will say that this is the
|
|
0:13:06
|
static_map
|
|
0:13:10
|
which we can see is defining not only
|
|
0:13:13
|
the regular crypto maps parameters
|
|
0:13:16
|
but is defining the client
|
|
0:13:19
|
authorization and the client authentication parameters
|
|
0:13:24
|
where the list here, these are the AAA groups that we define
|
|
0:13:29
|
in this case these were called the easy VPN
|
|
0:13:33
|
_aaa
|
|
0:13:38
|
So as you could see, there is a lot of additional steps here
|
|
0:13:41
|
as compared to, just the lan to lan VPN
|
|
0:13:44
|
so its a real good idea to use the documentation examples
|
|
0:13:46
|
to make sure that you are not leaving out an individual step
|
|
0:13:51
|
when we take a look at the Dynamic Virtual Tunnel Interfaces or the DVTIs
|
|
0:13:56
|
its a little bit more straight forward now with that logic
|
|
0:13:59
|
but with the crypto maps we need not only the static maps
|
|
0:14:02
|
but also the dynamic maps
|
|
0:14:06
|
So the dynamic map then is being referenced from the static map
|
|
0:14:16
|
then unless the, we have this applied to
|
|
0:14:19
|
the interface
|
|
0:14:23
|
So lets review this again real quick
|
|
0:14:26
|
first thing we have is our normal phase I parameters
|
|
0:14:29
|
so this policy, we could have multiple ones
|
|
0:14:31
|
just depends on what the individual vpn client is going to support
|
|
0:14:35
|
Now we have our specific phase 1.5 options
|
|
0:14:40
|
so what is the group name
|
|
0:14:42
|
what is the group password
|
|
0:14:45
|
once the group authentication occurs
|
|
0:14:50
|
then we need to do the extended authentication
|
|
0:14:55
|
we are saying username cisco password cisco
|
|
0:14:57
|
is being checked via local
|
|
0:15:00
|
authentication and local network authorization
|
|
0:15:04
|
this is then what is being referred to
|
|
0:15:06
|
from the static crypto map
|
|
0:15:09
|
the authentication should use the group easyvpn_aaa
|
|
0:15:14
|
the same with the isakmp authorization
|
|
0:15:20
|
we are then assigning the client an ip address
|
|
0:15:24
|
that is coming from this ip address pool called easyvpn_pool
|
|
0:15:29
|
likewise we could forward this to an external DHCP server
|
|
0:15:35
|
access list 199 is then specifying the split tunnelling
|
|
0:15:40
|
which is essentially saying that from the vpn client's perspective
|
|
0:15:44
|
any traffic going to 172.16.34.0
|
|
0:15:49
|
or 172.16.4.0
|
|
0:15:51
|
thats whats going to be sent over the tunnel
|
|
0:15:56
|
then we have our additional phase II parameters, which are going to be the transform set
|
|
0:16:01
|
which is called from the dynamic crypto map
|
|
0:16:04
|
which is called from the static crypto map
|
|
0:16:07
|
then finally the static crypto map, this is whats going to be applied to the actual interface
|
|
0:16:14
|
Now notice that one of the other key points here is the different
|
|
0:16:17
|
with the easy VPN server configuration versus the static lan to lan tunnel
|
|
0:16:24
|
that the crypto map does not define the ipsec peer
|
|
0:16:29
|
nor is it to find the proxy acl
|
|
0:16:33
|
and the reason why is that with the easy vpn server
|
|
0:16:37
|
we do not know what the initiator's ip address is going to be
|
|
0:16:41
|
before the tunnel is started
|
|
0:16:44
|
and thats what the crypto dynamic map is doing for
|
|
0:16:48
|
its allowing us to bind this to the interface
|
|
0:16:50
|
without having to use the set peer command
|
|
0:16:53
|
or without having to match the address for the acl
|
|
0:16:58
|
Now the proxy acl essentially is
|
|
0:17:00
|
changed into the split tunnelling acl
|
|
0:17:04
|
but the key is that, the any here
|
|
0:17:07
|
this is not known, where we are actually going to send the traffic
|
|
0:17:10
|
until the VPN client
|
|
0:17:12
|
actually initiates the tunnel
|
|
0:17:15
|
So now lets go on and apply this onto router3, which is the server
|
|
0:17:23
|
the particular interface that we are going to be using
|
|
0:17:26
|
for the crypto map, if we take a look at the topology
|
|
0:17:29
|
is this serial1/0.23
|
|
0:17:37
|
So lets see if this syntax is correct here
|
|
0:17:48
|
so everything looks good from their example
|
|
0:17:50
|
then last one we have on serial1/0.23
|
|
0:17:57
|
is to apply the static crypto map
|
|
0:18:06
|
we can see now isakmp is automatically enabled
|
|
0:18:08
|
next thing we are going to look at is the debug crypto isakmp
|
|
0:18:13
|
So I want to see all of the phase I negotiation parameters
|
|
0:18:17
|
additionally I am going to send this log to the buffer, lets say logging buffer7
|
|
0:18:23
|
and I am going make the log buffer size very large
|
|
0:18:27
|
because this is going to generate a lot of output
|
|
0:18:30
|
and we will say clear log
|
|
0:18:38
|
So our next step now would be to configure the test pc
|
|
0:18:41
|
the actual client configuration here is going to pretty straight forward, the only thing we need to apply
|
|
0:18:48
|
is to tell the client, what is the service address that we want to initiate the connection to
|
|
0:18:53
|
what is the group username and password
|
|
0:18:56
|
and then what is the extended authentication username and password
|
|
0:18:59
|
once we actually establish the tunnel
|
|
0:19:04
|
so now from the windows machine
|
|
0:19:08
|
lets go to the VPN client
|
|
0:19:12
|
and we are going to start a new connection
|
|
0:19:23
|
from here we see the group
|
|
0:19:24
|
authentication name and password
|
|
0:19:26
|
this is what we configured as the
|
|
0:19:29
|
crypto ipsec configuration group
|
|
0:19:33
|
which again is the
|
|
0:19:34
|
the client configuration group, the isakmp client configuration group, I should say
|
|
0:19:39
|
So this username here
|
|
0:19:42
|
is what goes in the group name
|
|
0:19:45
|
So we have the easyvpn_group
|
|
0:19:51
|
and the password is what we define is essentially the pre shared key
|
|
0:19:56
|
which is defined here
|
|
0:19:59
|
I now need to know whats the peer address that we are connecting to
|
|
0:20:03
|
which in this case is going to be the
|
|
0:20:05
|
200.0.23.3 address
|
|
0:20:10
|
so the outside interface of router3
|
|
0:20:14
|
and the connection entry or the description this could be any
|
|
0:20:17
|
value that we want, I will say r3
|
|
0:20:22
|
if we look at the other options
|
|
0:20:24
|
normally by default the vpn client is going to try to do ipsec over udp
|
|
0:20:30
|
for transparent tunneling
|
|
0:20:32
|
we can also configure it to do tunnelling over tcp
|
|
0:20:37
|
and we will see exactly, why we would want to do that here
|
|
0:20:40
|
its going to depend on whether we are going through a network address translation
|
|
0:20:44
|
or whether we are going through any type of stateful
|
|
0:20:47
|
or stateless firewall filtering
|
|
0:20:52
|
but otherwise from the client's configuration, this is pretty much all we need to do
|
|
0:20:56
|
just to find the address here
|
|
0:20:58
|
the group name and the group password
|
|
0:21:03
|
Now once we double click on the entry
|
|
0:21:06
|
assuming that everything is correct in phase I on the server
|
|
0:21:11
|
we should see that the user name
|
|
0:21:14
|
and password box is going to show up
|
|
0:21:17
|
this here is for the extended authentication
|
|
0:21:22
|
what this now means, if we were to look back at the command line of the router3
|
|
0:21:27
|
is that phase I is now complete
|
|
0:21:33
|
So anytime you are connecting to vpn client
|
|
0:21:35
|
and you get to this point where the username and password show up
|
|
0:21:39
|
it means that phase I was successful
|
|
0:21:41
|
and now you are proceeding on to phase 1.5, for the extended authentication
|
|
0:21:48
|
before I actually put the username and the password in
|
|
0:21:51
|
lets take a look at the debug on router3
|
|
0:21:57
|
where it says we received a packet from the
|
|
0:22:00
|
client destination port is 500
|
|
0:22:03
|
which is the isakmp
|
|
0:22:06
|
port, so it says we are starting a new undebug here
|
|
0:22:10
|
says we are now trying to start a new isakmp sa
|
|
0:22:23
|
next it says, we are going to start checking our isakmp policies
|
|
0:22:28
|
Now we will see here
|
|
0:22:30
|
different that what we saw in lan to lan tunnels
|
|
0:22:32
|
is that vpn client is going to offer tonnes and tonnes
|
|
0:22:37
|
of different policy
|
|
0:22:39
|
where we could see the vpn client says, it could run AES, SHA
|
|
0:22:44
|
group number 2
|
|
0:22:45
|
then it would run extended authentication
|
|
0:22:48
|
but initially use a pre shared key
|
|
0:22:51
|
and the particular lifetime value
|
|
0:22:56
|
it could also support
|
|
0:22:58
|
AES with MD5 group number 2
|
|
0:23:01
|
it could support
|
|
0:23:03
|
AES with SHA and use just pre shared authentication
|
|
0:23:07
|
and not do extended authentication
|
|
0:23:11
|
and eventually we should see, ideally towards the bottom
|
|
0:23:15
|
that one of these policies is going to match
|
|
0:23:18
|
so finally, I guess, at the end it says that
|
|
0:23:20
|
if they are offering 3DES with MD5
|
|
0:23:24
|
with extended authentication
|
|
0:23:27
|
group number 2, this is what is acceptable
|
|
0:23:34
|
next step we should see that we now proceed on to
|
|
0:23:37
|
phase 1.5
|
|
0:23:40
|
and we could see here, it says, the state is am as opposed to mn
|
|
0:23:46
|
where the vpn server and the vpn client they are running
|
|
0:23:49
|
in aggressive mode for phase I
|
|
0:23:51
|
as opposed to running in main mode
|
|
0:23:56
|
So now it says our security association is doing
|
|
0:23:59
|
pre shared key authentication plus extended authentication
|
|
0:24:03
|
where the pre shared key thats coming from the group name and the group password
|
|
0:24:09
|
So once we have agreed on, isakmp for phase I
|
|
0:24:12
|
Now the authentication has to have
|
|
0:24:15
|
we see the pre shared key replied
|
|
0:24:20
|
the SA authentication status is authenticated
|
|
0:24:25
|
So this now means that the group username and password was correct
|
|
0:24:29
|
next step is that we are going on
|
|
0:24:32
|
to the mode configuration and the extended authentication
|
|
0:24:37
|
So now we will see the
|
|
0:24:39
|
mode configuration for extended authentication
|
|
0:24:43
|
we are going to ask for the username and password
|
|
0:24:46
|
so we are requesting those attributes the username and password
|
|
0:24:50
|
then eventually we are going to see, its going to time out because I didn't
|
|
0:24:53
|
configure or I didn't type in the username and password
|
|
0:24:56
|
but atleast upto this point we know that the basic phase I is working
|
|
0:25:00
|
and that the group username and the group password was correct
|
|
0:25:06
|
if we were to debug crypto
|
|
0:25:09
|
isakmp again
|
|
0:25:11
|
then to go to the vpn client
|
|
0:25:14
|
and the modify this so that the password was incorrect
|
|
0:25:20
|
which again is the group password, lets type anything in here
|
|
0:25:30
|
we should see on router3 now
|
|
0:25:33
|
that it never gets to the portion
|
|
0:25:35
|
where we start to run extended authentication
|
|
0:25:39
|
because the IKE packet from
|
|
0:25:42
|
the client was not encrypted and it should have been
|
|
0:25:47
|
this means that the authentication didn't happened
|
|
0:25:52
|
Now we looked at this before when we were doing some troubleshooting on the lan to lan vpns
|
|
0:25:56
|
its not really a very obvious
|
|
0:25:58
|
troubleshooting message or really not an obvious log message
|
|
0:26:02
|
because it doesn't simply say
|
|
0:26:04
|
the password is wrong or the authentication has failed
|
|
0:26:07
|
what it saying is that with the username and password
|
|
0:26:11
|
You should be encrypting
|
|
0:26:13
|
the phase I ISA
|
|
0:26:16
|
when it gets to me
|
|
0:26:17
|
says it supposed to be encrypted but it wasn't
|
|
0:26:20
|
this either means that some is trying to do some sort of man in the middle attack
|
|
0:26:24
|
by modifying the packet
|
|
0:26:27
|
or more than likely just that the username and password combination is wrong
|
|
0:26:32
|
so now lets go to our next step, where the
|
|
0:26:35
|
the group username and password is correct
|
|
0:26:37
|
or modify the tunnel again
|
|
0:26:49
|
we can see the extended authentication, username and password box shows up
|
|
0:26:54
|
so this means that everything in phase I goes correct
|
|
0:27:01
|
Now I will enter the username and password cisco, cisco as I configured locally here
|
|
0:27:06
|
we should now see that for
|
|
0:27:14
|
we could see its a lot of debug output here
|
|
0:27:27
|
So lets go back to where the phase I was completed
|
|
0:27:38
|
which is here, so now the group authentication was correct
|
|
0:27:42
|
the server is asking for the extended authentication, both the username and the password
|
|
0:27:48
|
we should see the authentication come back in
|
|
0:27:53
|
it says that we go the reply
|
|
0:27:57
|
they replied with the username and password
|
|
0:28:00
|
and it says the error is done with
|
|
0:28:03
|
extended or not there, it says that the
|
|
0:28:06
|
we are done with the extended authentication request and reply exchange
|
|
0:28:11
|
this essentially means that the authentication was correct
|
|
0:28:14
|
where again it kind of an odd output, the way that this says, it says its an error
|
|
0:28:19
|
actually no, its an error false
|
|
0:28:21
|
So there is no error message actually here
|
|
0:28:24
|
we are done with extended authentication request and reply so the authentication was good
|
|
0:28:29
|
Next what we should see
|
|
0:28:30
|
is that we move on to the mode configuration
|
|
0:28:34
|
this is where we will see all of these individual options
|
|
0:28:38
|
Says ipv4 address, the netmask, the dns server
|
|
0:28:42
|
the netbios name server which will be the WINS server
|
|
0:28:46
|
we can give them a banner
|
|
0:28:48
|
can they save their password locally
|
|
0:28:51
|
whats their domain name
|
|
0:28:53
|
are we going to do split tunnelling, split dns
|
|
0:28:55
|
perfect forward secrecy
|
|
0:28:57
|
are going to give their web browser a proxy
|
|
0:29:01
|
are we going to
|
|
0:29:03
|
assign them a hostname
|
|
0:29:05
|
so we can see that there is a lot of individual options that we can
|
|
0:29:08
|
apply under here
|
|
0:29:10
|
usually the ones that are important here would be
|
|
0:29:13
|
what are the address and the mask that we are applying on to them
|
|
0:29:19
|
and are we doing split tunnelling
|
|
0:29:24
|
then are we offering them transparent tunnel
|
|
0:29:29
|
where in this case
|
|
0:29:31
|
we are not offering them transparent tunneling yet
|
|
0:29:34
|
so it says now we have the
|
|
0:29:36
|
the access list, we are giving them is
|
|
0:29:38
|
from 172.16.34.0
|
|
0:29:42
|
and 172.16.4.0
|
|
0:29:47
|
then we should see them assign an address
|
|
0:29:58
|
which is here, says we are allocating the address 172.16.255.1
|
|
0:30:06
|
Now at this point, we go through
|
|
0:30:09
|
this phase 1.5 is completed
|
|
0:30:12
|
we should then see the isakmp sa
|
|
0:30:15
|
is now in QM_IDLE state or quick mode idle
|
|
0:30:19
|
this now means that the easy vpn client
|
|
0:30:22
|
can start offering the proposals
|
|
0:30:24
|
for the ipsec transform set, or the phase II
|
|
0:30:29
|
isakmp negotiation
|
|
0:30:32
|
where we see that the first thing it offers, it says
|
|
0:30:34
|
I want to run AES with md5
|
|
0:30:37
|
256 bit AES
|
|
0:30:40
|
I want to run in tunnel mode
|
|
0:30:43
|
and these are the security association lifetime values
|
|
0:30:50
|
says these attributes are acceptable, so these are the ones, we are going to use
|
|
0:30:59
|
ESP AES with
|
|
0:31:01
|
SHA
|
|
0:31:04
|
these ones are acceptable as well, this ones says the ipsec policy invalidate proposal
|
|
0:31:09
|
with error 256
|
|
0:31:12
|
which
|
|
0:31:14
|
most likely is this, which is
|
|
0:31:19
|
a compression algorithm, that is trying to request
|
|
0:31:25
|
So the vpn client is trying to ask for
|
|
0:31:27
|
for compression
|
|
0:31:28
|
the vpn server is saying no
|
|
0:31:30
|
So now it gets down to, the next one, we could see its saying the
|
|
0:31:34
|
these particular attributes are fine
|
|
0:31:36
|
but then, this one is not, that whats the error must mean
|
|
0:31:41
|
So we go all the way down to the bottom, we will see figure out which one is actually choosing
|
|
0:31:46
|
which again see, it has to go through 16 different proposals
|
|
0:31:53
|
but then it says that the phase II sa policy is not acceptable
|
|
0:31:59
|
quick mode is being rejected
|
|
0:32:04
|
essentially what this means now
|
|
0:32:06
|
is that the transform set, I have configured on router3
|
|
0:32:09
|
is not compatible with this particular version
|
|
0:32:12
|
of the vpn client
|
|
0:32:16
|
So lets look at the show run section crypto map
|
|
0:32:19
|
or show run section crypto
|
|
0:32:22
|
I am going to have to change now whatever
|
|
0:32:25
|
this transform set is
|
|
0:32:27
|
in order to be something compatible
|
|
0:32:30
|
basically what this means, whatever the particular version we are running this, lets take a look at this, its
|
|
0:32:35
|
4.8
|
|
0:32:37
|
then sub to this 02.0010
|
|
0:32:41
|
it doesn't support a DES
|
|
0:32:44
|
because this is one of the less secure algorithms
|
|
0:32:48
|
So lets say we are going to replace this with something a bit stronger
|
|
0:32:52
|
lets try 3DES, we will say 3
|
|
0:32:54
|
crypto ipsec
|
|
0:32:56
|
transform set 3des_sha
|
|
0:33:00
|
is esp 3des and esp sha
|
|
0:33:05
|
then under the dynamic crypto map
|
|
0:33:09
|
I will say no set transform set to des sha
|
|
0:33:14
|
we will set this to 3des_sha
|
|
0:33:21
|
then lets debug crypto isakmp
|
|
0:33:57
|
if we now look at the very last portion of the negotiation
|
|
0:34:01
|
it says it got the proposal number 12
|
|
0:34:05
|
and it offered esp 3des
|
|
0:34:08
|
with sha were running in tunnel mode
|
|
0:34:11
|
with these particular sa lifetimes
|
|
0:34:14
|
these attributes are acceptable
|
|
0:34:17
|
and now it says that phase-II is complete
|
|
0:34:24
|
from router3 which is the server, if we were to look at now the show crypto isakmp sa
|
|
0:34:31
|
just like any of the lan to lan tunnels
|
|
0:34:33
|
we should see this as QM_IDLE
|
|
0:34:36
|
which means the phase I isakmp sa was successfully established
|
|
0:34:42
|
if we look at the show crypto ipsec sa
|
|
0:34:46
|
we should see that now the phase II ipsec sa is working
|
|
0:34:52
|
it says that the peer
|
|
0:34:54
|
is 192.168.118.100
|
|
0:34:59
|
we have assigned them an address of 172.16.255.2
|
|
0:35:05
|
the particular sa is using 3des and sha
|
|
0:35:12
|
if we actually test this out, now we go to the windows machine
|
|
0:35:17
|
and open up the vpn client again
|
|
0:35:19
|
under the status, we want to go to the statistics
|
|
0:35:25
|
this output here, the tunnel details
|
|
0:35:28
|
this essentially the equivalent of looking it to show crypto ipsec sa on the router
|
|
0:35:34
|
its showing me the address that I was negotiating
|
|
0:35:37
|
it shows me the server's address, thats the peer
|
|
0:35:40
|
it shows me the crypto transform set
|
|
0:35:43
|
So we are using 3des and sha
|
|
0:35:47
|
says packets
|
|
0:35:48
|
right now nothing is being encrypted or decrypted because we are not actually sending anything over the tunnel yet
|
|
0:35:54
|
transparent tunnelling is inactive
|
|
0:35:57
|
this means that we are going to be sending the traffic natively over esp
|
|
0:36:02
|
its not going to be encapsulated on udp
|
|
0:36:05
|
its not going to be encapsulated inside of tcp
|
|
0:36:10
|
next if we go to the route details
|
|
0:36:13
|
these secure routes
|
|
0:36:15
|
this is the split tunnelling acl
|
|
0:36:18
|
that the easy vpn server has configured
|
|
0:36:24
|
the result of this, if we were to go to the command line
|
|
0:36:27
|
and look at the ipconfig
|
|
0:36:30
|
we see that we have this address 172.16.255.2
|
|
0:36:36
|
and if we look at the route print
|
|
0:36:39
|
we should see that there is two new routes installed here
|
|
0:36:44
|
which are the 172.16.4.0
|
|
0:36:48
|
and 172.16.34.0
|
|
0:36:53
|
both of these are using the interface
|
|
0:36:55
|
172.16.255.2
|
|
0:36:59
|
which essentially is the vpn adapter
|
|
0:37:03
|
So now lets test our final configuration
|
|
0:37:05
|
assuming everything is working
|
|
0:37:08
|
what we should be able to do
|
|
0:37:10
|
is to go to router4
|
|
0:37:12
|
and look at the debug
|
|
0:37:15
|
ip
|
|
0:37:18
|
icmp
|
|
0:37:20
|
debug ip icmp
|
|
0:37:22
|
then from the test pc we are going to ping this address of router4
|
|
0:37:28
|
ideally what we should see
|
|
0:37:29
|
is that the traffic is coming from
|
|
0:37:31
|
the 172.16
|
|
0:37:34
|
.255 address
|
|
0:37:37
|
this is going to tell us that
|
|
0:37:39
|
the tunnel was properly established
|
|
0:37:42
|
that the test pc was actually allocated that address
|
|
0:37:46
|
and there is nothing filtering the traffic
|
|
0:37:48
|
as if comes from the client
|
|
0:37:50
|
going over the tunnel
|
|
0:37:54
|
now if router4 is able to respond and the test pc actually gets the ping replies back in
|
|
0:37:59
|
then we know that the tunnel is working bidirectional
|
|
0:38:03
|
So next on router4
|
|
0:38:06
|
lets say debug
|
|
0:38:08
|
debug ip icmp
|
|
0:38:12
|
then on the test pc lets ping
|
|
0:38:15
|
172.16.4.4
|
|
0:38:17
|
and I will say -t
|
|
0:38:19
|
which is going to
|
|
0:38:21
|
be a continuous ping
|
|
0:38:28
|
router4 says I am sending an echo reply
|
|
0:38:32
|
going to 172.16.255.2
|
|
0:38:37
|
but notice we have a problem now here, it says
|
|
0:38:39
|
we are receiving an icmp host unreachable message
|
|
0:38:43
|
from 172.16.34.3
|
|
0:38:52
|
Now what this means here is that, at a minimum
|
|
0:38:55
|
we know that router4 is receiving the traffic in
|
|
0:39:02
|
So the packet is properly coming into tunnel
|
|
0:39:04
|
4 is getting it and trying to reply
|
|
0:39:07
|
its sending the packet back toward 3
|
|
0:39:11
|
but 3 is replying back saying, I don't know how to reach that host
|
|
0:39:17
|
and the reason why
|
|
0:39:19
|
is that if we look at the routing table
|
|
0:39:22
|
and lets undebug all first on router3
|
|
0:39:24
|
if we look at the routing table of router3
|
|
0:39:27
|
we don't have an entry for the pool address
|
|
0:39:34
|
that we are allocating the users
|
|
0:39:39
|
now we haven't really doubt with this problem yet in the previous lan to lan vpns
|
|
0:39:44
|
because that topology was pre configured with dynamic routing
|
|
0:39:48
|
and we looked at the examples of using the GRE tunnels
|
|
0:39:51
|
or the static virtual tunnel interfaces
|
|
0:39:54
|
we were able likewise, to run dynamic routing protocols over there
|
|
0:39:57
|
which are going to solve any of the lan to lan routing issues
|
|
0:40:02
|
but with the remote access vpns, the easy vpn client
|
|
0:40:07
|
there is no way that we can really dynamically
|
|
0:40:10
|
route back to the sources
|
|
0:40:12
|
because we are the one who is manually
|
|
0:40:16
|
issuing or manually allocating the addresses down to them
|
|
0:40:21
|
So its not necessarily an ipsec problem
|
|
0:40:23
|
but is an issue that we have to address
|
|
0:40:26
|
that just like we saw with the IOS and the ASA before
|
|
0:40:30
|
the network address translation process and the routing process were separate
|
|
0:40:34
|
same thing is going to be true about ipsec
|
|
0:40:36
|
the ipsec tunnel doesn't have anything to do with the routing
|
|
0:40:40
|
to separate unrelated problem that we have to solve
|
|
0:40:43
|
So on router3
|
|
0:40:45
|
when the packet is coming back in and it is trying to reach 172.16.255.2
|
|
0:40:54
|
says I don't have a route to that
|
|
0:40:57
|
So it actually goes to my eigrp
|
|
0:40:59
|
summary which is a default route going to Null0
|
|
0:41:02
|
and router3 is dropping the packet
|
|
0:41:05
|
this is why router3 is getting that icmp unreachable back in
|
|
0:41:12
|
Now there is a couple of different solutions for this particular problem
|
|
0:41:16
|
we could just go to router3
|
|
0:41:18
|
and statically tell it
|
|
0:41:20
|
to point a route
|
|
0:41:22
|
towards the interface with the crypto map
|
|
0:41:25
|
for that pool, the 172.168.255.0/24
|
|
0:41:33
|
or we could tell it as the vpn client connect
|
|
0:41:37
|
I want to automatically put their addresses into the routing table
|
|
0:41:40
|
which is known as the reverse route injection or the RRR feature
|
|
0:41:48
|
Now either these are going to be valid
|
|
0:41:51
|
really the only time that its going to make a difference
|
|
0:41:53
|
whether you are using the reverse route injection versus the
|
|
0:41:56
|
the manual routing, or which is sometimes called a hold down route
|
|
0:42:01
|
is how many potential vpn clients do you have connecting
|
|
0:42:06
|
so if would have a network designed, where lets say
|
|
0:42:08
|
theoretically you have 10000 vpn clients connecting
|
|
0:42:12
|
then you wouldn't want to install 10000 host routes into your routing table
|
|
0:42:16
|
you probably be better off with
|
|
0:42:18
|
with static routes that are pointing to the dhcp pools
|
|
0:42:22
|
for those particular vpn clients
|
|
0:42:29
|
Now the other potential issue
|
|
0:42:31
|
would be what you if you were to have multiple vpn servers
|
|
0:42:35
|
where we have router1
|
|
0:42:38
|
and router2 on the edge
|
|
0:42:40
|
they are both listening for the easy vpn server connections
|
|
0:42:44
|
and if they are sharing the same dhcp pools
|
|
0:42:49
|
so lets say we have router3 here
|
|
0:42:51
|
and then somewhere else in the network we have the dhcp server
|
|
0:42:56
|
if the vpn client comes in this way
|
|
0:43:01
|
and it asks for an address from the vpn
|
|
0:43:04
|
or from the dhcp server
|
|
0:43:06
|
So the dhcp server allocates it to the client
|
|
0:43:10
|
the rest of the network would then need to know, lets say this client is A
|
|
0:43:14
|
it would need to know that A's route is reachable via this vpn server
|
|
0:43:19
|
as opposed to be reachable via this one
|
|
0:43:24
|
so its really more of a design issue here, whether
|
|
0:43:26
|
you have multiple
|
|
0:43:28
|
vpn servers on the edge that are showing the same
|
|
0:43:31
|
dhcp pool for the client
|
|
0:43:33
|
then we would need to use the exact host routing
|
|
0:43:36
|
to make sure that we have the correct path
|
|
0:43:38
|
or back to the actual client
|
|
0:43:41
|
but in our particular design here we only have one vpn server
|
|
0:43:44
|
so its not really going to make a difference
|
|
0:43:46
|
I could just go to router3
|
|
0:43:48
|
and say I have the route 172.16.255.0/24
|
|
0:43:57
|
that goes out my point to point
|
|
0:43:59
|
sub interface serial1/0.23
|
|
0:44:04
|
now since router4 is already defaulting to router3
|
|
0:44:10
|
we could see now we are not getting that
|
|
0:44:12
|
there host unreachable message back in from router3
|
|
0:44:17
|
if we were to look at router3, and look at now the show crypto
|
|
0:44:22
|
ipsec sa
|
|
0:44:25
|
what we would want to know is
|
|
0:44:28
|
are we receiving
|
|
0:44:29
|
the packets in
|
|
0:44:31
|
and are we sending packets back out
|
|
0:44:35
|
so again this first line this is the outbound packets
|
|
0:44:39
|
the second line this is the inbound packets
|
|
0:44:42
|
so I know I am receiving packets in the tunnel and then I am sending packets back out of the tunnel
|
|
0:44:49
|
if we look at now, the test pc
|
|
0:44:53
|
there is still something wrong with the connectivity here
|
|
0:44:57
|
where I now know based on this corners
|
|
0:45:00
|
that at a minimum
|
|
0:45:01
|
the packets are going from the test pc out its tunnel
|
|
0:45:05
|
they get to 33 sending them to 4
|
|
0:45:08
|
4 is now replying
|
|
0:45:10
|
and 3 is sending them this direction
|
|
0:45:14
|
I could tell this just based on the ipsec sa corners
|
|
0:45:19
|
Now the test pc is not actually receiving the traffic back in
|
|
0:45:23
|
So it could be a potential
|
|
0:45:25
|
where the traffic is being filtered out
|
|
0:45:29
|
So just like we saw in the lan to lan tunnels
|
|
0:45:32
|
when I look at the ipsec sa
|
|
0:45:35
|
and it shows the packets are being encapsulated and decapsulated
|
|
0:45:40
|
I now know its not a problem with phase I negotiation
|
|
0:45:44
|
phase 1.5 negotiation, the mode configuration or the extended authentication
|
|
0:45:49
|
nor could it be a problem with the phase II negotiation
|
|
0:45:54
|
because otherwise I wouldn't create
|
|
0:45:56
|
the ipsec security association
|
|
0:45:59
|
its now something related to the data plane, some sort of
|
|
0:46:03
|
most likely filtering or may be like a routing problem in the network
|
|
0:46:08
|
Now when we look at our topology here
|
|
0:46:10
|
we know that we have ASA1, thats in the transit path
|
|
0:46:15
|
and if the test pc is not being offered transparent tunnelling
|
|
0:46:21
|
so its running the ipsec tunnel directly over esp
|
|
0:46:26
|
the ASA is going to drop this traffic as it tries to move from the outside back in
|
|
0:46:35
|
So its the same type of filtering problem that we saw before
|
|
0:46:38
|
because remember with the phase I isakmp sa
|
|
0:46:42
|
that is a bidirectional udp port 500 tunnel
|
|
0:46:46
|
So the test pc initiates it
|
|
0:46:48
|
from the ASA's perspective its goes from the inside to out
|
|
0:46:52
|
and then it returns
|
|
0:46:54
|
if we were to go to ASA1 and look at the show connections
|
|
0:46:59
|
we see that the UDP 500 connection was originated from the inside
|
|
0:47:04
|
and were expecting it to come from the outside back in
|
|
0:47:08
|
however for the ipsec sa
|
|
0:47:12
|
that is two unidirectional sa-s
|
|
0:47:15
|
one that was originated from the inside to out
|
|
0:47:18
|
then one that came from the outside to back in
|
|
0:47:23
|
if we were to turn the logging on
|
|
0:47:27
|
on the ASA, most likely we are going to see
|
|
0:47:36
|
is that these packets are going to get dropped
|
|
0:47:40
|
as they come in on the outside interface
|
|
0:47:46
|
So lets see, is the
|
|
0:47:49
|
the test pc is sending the
|
|
0:47:53
|
the pings, lets try to start this again
|
|
0:47:56
|
lets disconnect the tunnel and reconnect it
|
|
0:48:00
|
and we will see, what the log of the ASA shows
|
|
0:48:12
|
So I will connect to tunnel
|
|
0:48:21
|
and start the ping again
|
|
0:48:27
|
the ASA says I am denying inbound traffic from router3
|
|
0:48:32
|
that is trying to return back to the VPN client
|
|
0:48:38
|
and we can see, this is protocol number 54 esp
|
|
0:48:43
|
so without transparent tunnelling configured, which means that we are not encapsulating the
|
|
0:48:47
|
the esp inside of udp or inside of tcp
|
|
0:48:51
|
we would need to make sure that we have native ip protocol 50 transport
|
|
0:48:55
|
from the client to the server and then back
|
|
0:49:00
|
Now there is a couple of different solutions for this type of problem here
|
|
0:49:03
|
we talked about two of them already
|
|
0:49:05
|
which I could simply go to the ASA
|
|
0:49:08
|
and say something like access list outside in
|
|
0:49:12
|
permit esp any any
|
|
0:49:15
|
and then allow this in on the outside interface
|
|
0:49:18
|
So it is just static exception
|
|
0:49:21
|
the other thing I could do is under the global policy
|
|
0:49:26
|
I could inspect ipsec pass through
|
|
0:49:30
|
which would then dynamically allow
|
|
0:49:32
|
the esp traffic to return back in
|
|
0:49:35
|
or the third option
|
|
0:49:37
|
I could configure the
|
|
0:49:39
|
easyvpn server
|
|
0:49:41
|
which is router3 in this case
|
|
0:49:43
|
I could to tell it to offer the client transparent tunnelling
|
|
0:49:47
|
transparent tunnelling over udp
|
|
0:49:50
|
Now with transparent tunnelling there is three different options that we can use
|
|
0:49:54
|
in order to accomplish this
|
|
0:49:56
|
where the overall goal in either the case
|
|
0:49:59
|
is that we don't want to encapsulate the tunnel directly into the esp
|
|
0:50:04
|
that we are going to send it either over udp
|
|
0:50:07
|
or over tcp
|
|
0:50:09
|
and which one do we choose depend on a couple of different options
|
|
0:50:13
|
which particular platform we are using the server
|
|
0:50:16
|
for the server, whether its the IOS or its the ASA
|
|
0:50:19
|
and whether or not we are going through a network address translation
|
|
0:50:24
|
Now first of these three options for transparent tunnelling
|
|
0:50:27
|
is known as the NAT transparent or the NAT traversal
|
|
0:50:32
|
with NAT traversal
|
|
0:50:34
|
the ipsec tunnel is going to be encapsulated inside of udp
|
|
0:50:38
|
port 4500
|
|
0:50:43
|
Now the key with NAT transparency or NAT traversal
|
|
0:50:47
|
is that when the easyvpn client
|
|
0:50:49
|
starts the negotiation to the server
|
|
0:50:52
|
the server is going to see that the
|
|
0:50:54
|
isakmp packet which is our udp port 500 packet
|
|
0:50:58
|
is coming from a different source address
|
|
0:51:01
|
then the IKE identifier in the actual payload
|
|
0:51:06
|
So in our particular case, when we look at the topology
|
|
0:51:09
|
if the easyvpn client was the test pc
|
|
0:51:13
|
with an address of 192.168.118.100
|
|
0:51:20
|
but it was being translated to an address on the outside lets say the 200.0.111.100 address
|
|
0:51:30
|
when router3 receives the isakmp packet in
|
|
0:51:33
|
its going to say the actual packet came from the source address
|
|
0:51:36
|
but the IKE identifier
|
|
0:51:39
|
is this inside local address 192.168
|
|
0:51:44
|
and simply based on that fact that it sees the difference between the
|
|
0:51:47
|
pre and the post NAT address
|
|
0:51:50
|
the easyVPN server is automatically going to offer
|
|
0:51:52
|
the transparent tunnelling at udp port 4500
|
|
0:51:58
|
the second option
|
|
0:51:59
|
would be to configure
|
|
0:52:01
|
transparent tunnelling
|
|
0:52:04
|
over udp
|
|
0:52:06
|
which is used in case is
|
|
0:52:08
|
where we are not going through a Network Address Translation
|
|
0:52:11
|
but we still want to encapsulate the esp packet inside of udp
|
|
0:52:17
|
and typically this is going to be running
|
|
0:52:19
|
over upd port 10000
|
|
0:52:23
|
Now the key difference between these two
|
|
0:52:25
|
is that the NAT transparency or the NAT traversal, which is our first option
|
|
0:52:29
|
and this is a standardised implementation
|
|
0:52:32
|
its an RFC defined implementation
|
|
0:52:34
|
of how
|
|
0:52:35
|
the , the esp packets can be encapsulated inside of udp
|
|
0:52:40
|
with this second option of sending them over udp port 10000
|
|
0:52:44
|
this is a cisco proprietary implementation
|
|
0:52:47
|
that came from the vpn 3000 concentrator
|
|
0:52:52
|
so we will see that the second with using udp port 10000
|
|
0:52:55
|
we can use this when the ASA is the easy server
|
|
0:52:59
|
but not when the router is the easyVPN server
|
|
0:53:03
|
the third option we have
|
|
0:53:06
|
is the same type of transparent tunnelling
|
|
0:53:09
|
which is going to run over tcp
|
|
0:53:13
|
as opposed to udp
|
|
0:53:16
|
and this likely udp is going to use tcp port 10000 by default
|
|
0:53:20
|
and this is a cisco proprietary implementation
|
|
0:53:23
|
Sometimes this is called the TCP
|
|
0:53:28
|
implementation
|
|
0:53:29
|
which is talking about the esp encapsulated inside of a tcp payload
|
|
0:53:36
|
so again for the first option, this is going to be used when we are going through a
|
|
0:53:39
|
Network Address Translation or a port address translation
|
|
0:53:43
|
second one is when the ASA is the easyVPN server
|
|
0:53:47
|
third one is either one of the router
|
|
0:53:48
|
or the ASA as the server, if we want to offer tcp as transparent tunnelling
|
|
0:53:55
|
Now the most common implementation of this
|
|
0:53:58
|
that you see is generally the first one
|
|
0:54:00
|
because in a design like we have here in our diagram
|
|
0:54:04
|
if the test pc is already on a private network
|
|
0:54:07
|
generally when this traffic is routed out to the public network like the internet
|
|
0:54:12
|
it is going to be going through a network address translation
|
|
0:54:15
|
and when the easyvpn server receives that
|
|
0:54:18
|
its automatically going to know that again
|
|
0:54:21
|
based on the disconnect between the IKE identifier
|
|
0:54:23
|
and where the actual isakmp packet is coming from
|
|
0:54:28
|
so in order to implement this type of tunnelling
|
|
0:54:30
|
the only thing that we need to do is go to the ASA
|
|
0:54:34
|
and tell it to do a Network Address Translation
|
|
0:54:37
|
from the inside addresses to the outside addresses
|
|
0:54:43
|
So next lets go to ASA1
|
|
0:54:46
|
and will actually configure this, this is to the context that is for
|
|
0:54:49
|
the connection to vlan 118, going down to the test pc
|
|
0:54:55
|
we will define a NAT rule for the inside, we will say nat
|
|
0:55:00
|
for packets that are coming in in the inside, we will name this room number1
|
|
0:55:03
|
and I will say that for simply any source address
|
|
0:55:06
|
I don't care where its coming from
|
|
0:55:09
|
but this is always going to be matched by that nat rule
|
|
0:55:13
|
then we will define our global translation
|
|
0:55:15
|
we will say as traffic goes to the outside
|
|
0:55:18
|
this is nat rule number 1
|
|
0:55:21
|
and we are simply going to translate it to the address thats on the
|
|
0:55:24
|
the outside interface
|
|
0:55:27
|
Now I could define a nat pool here
|
|
0:55:29
|
that were translating to, I could do static port translations
|
|
0:55:32
|
but just for the most basic example
|
|
0:55:35
|
we simply have this two commands, the nat inside 100
|
|
0:55:39
|
and the nat outside 1 interface
|
|
0:55:43
|
so now if we were to go to the test pc
|
|
0:55:46
|
and send packets from the inside to the outside, lets say we were to ping
|
|
0:55:51
|
router4's address again
|
|
0:55:54
|
we should see when router4, receives this
|
|
0:55:57
|
they should be getting translated
|
|
0:55:59
|
to
|
|
0:56:00
|
the outside interface of the ASA, which in this case is
|
|
0:56:05
|
the 200.0.111.118 address
|
|
0:56:12
|
if we were to look at the ASA and look at the show xlate
|
|
0:56:16
|
we should see the
|
|
0:56:18
|
the port address translation ASA1
|
|
0:56:21
|
the show xlate
|
|
0:56:24
|
we could see the port translation from the host on the inside
|
|
0:56:27
|
which is the 118.100
|
|
0:56:30
|
and we are translating that to the outside interface of the ASA
|
|
0:56:33
|
the 200.0.111.118
|
|
0:56:38
|
So now lets go to router3 and look at
|
|
0:56:40
|
the debug crypto isakmp
|
|
0:56:43
|
and what we should see now when the easyVPN client initiates the tunnel
|
|
0:56:48
|
router3 is automatically going to detect that it is behind a Network Address Translation
|
|
0:56:53
|
and it is going to operate udp port 4500 for the transparent tunnelling
|
|
0:56:59
|
if we go to the test pc
|
|
0:57:01
|
open up the vpn client
|
|
0:57:05
|
and authenticate with our extended authentication
|
|
0:57:11
|
what we should see is that when we actually
|
|
0:57:14
|
go through the phase I negotiation
|
|
0:57:18
|
and again we could see its a lot of output here for the debug
|
|
0:57:21
|
of phase I
|
|
0:57:25
|
but once this is complete, we could see it says
|
|
0:57:27
|
that for the actual phase II tunnel, the encapsulation is running over udp
|
|
0:57:33
|
and we will see the port number is listed
|
|
0:57:36
|
in the phase I negotiation
|
|
0:57:38
|
where it says that
|
|
0:57:40
|
we are sending a packet to 200.0.111.118
|
|
0:57:45
|
which remembers the outside interface as the ASA
|
|
0:57:48
|
and its going over udp port 4500
|
|
0:57:53
|
if we now look at the vpn client
|
|
0:57:56
|
and go to
|
|
0:57:59
|
the statistics
|
|
0:58:02
|
and look at the tunnel details
|
|
0:58:04
|
which remember similar to the show crypto ipsec sa
|
|
0:58:07
|
it says now the transparent tunnellings active
|
|
0:58:10
|
on udp port 4500
|
|
0:58:15
|
we could see now the packets are getting through
|
|
0:58:18
|
where previously the ASA was dropping them because they were esp
|
|
0:58:22
|
if we go to ASA1
|
|
0:58:26
|
and now look at the show connections
|
|
0:58:31
|
we should see two different connections
|
|
0:58:33
|
one of them for the phase I isakmp tunnel
|
|
0:58:38
|
which is udp port 50, excuse me, udp port 500
|
|
0:58:41
|
and then the phase II ipsec sa
|
|
0:58:45
|
which is now running over udp port 4500
|
|
0:58:51
|
Now again the key point
|
|
0:58:54
|
with this first option of transparent tunnelling, which is the NAT
|
|
0:58:56
|
traversal or the NAT transparency
|
|
0:58:59
|
is that we have to be going through either a Network Address Translation
|
|
0:59:03
|
or a Port Address Translation in order for the server to offer this
|
|
0:59:08
|
So it is going to be doing this by default
|
|
0:59:11
|
there is nothing special we need to configure on router3
|
|
0:59:14
|
on the client itself
|
|
0:59:16
|
if we look at the
|
|
0:59:18
|
the details of the tunnel
|
|
0:59:20
|
if we modify this connection
|
|
0:59:29
|
when we look at the transport option
|
|
0:59:32
|
we can see that the enable transparent tunnel feature is checked automatically
|
|
0:59:36
|
and its going to default to ipsec over udp, which is
|
|
0:59:39
|
NAT transparency or the
|
|
0:59:42
|
the port address translation and the network address translation
|
|
0:59:47
|
Now the other potential problem we could run into here
|
|
0:59:51
|
is either
|
|
0:59:53
|
if the tunnel is not going through a Network Address Translation
|
|
0:59:58
|
or if there is a firewall in the transit path
|
|
1:00:01
|
that is filtering udp port 500
|
|
1:00:06
|
because again when we look at the ASA here
|
|
1:00:08
|
it has two different connections
|
|
1:00:10
|
one of them is for the phase I isakmp sa
|
|
1:00:14
|
one of the them is for the phase II ipsec sa
|
|
1:00:18
|
where the phase II tunnel, this is what is changing with the NAT traversal,its now running over the udp port 4500
|
|
1:00:25
|
but for phase I this is still
|
|
1:00:27
|
isakmp over port 500
|
|
1:00:31
|
So if the firewall filtering policy was very strict
|
|
1:00:34
|
and we were to say something like access list
|
|
1:00:37
|
outside in
|
|
1:00:40
|
deny udp any any equal to 500
|
|
1:00:46
|
then ip access group outside in
|
|
1:00:50
|
in interface
|
|
1:00:52
|
outside
|
|
1:00:54
|
the issue that we are going to run into now
|
|
1:00:57
|
is that even if the tunnel
|
|
1:01:00
|
is trying to use the NAT
|
|
1:01:01
|
traversal or the NAT transparency
|
|
1:01:04
|
we would see that the phase I negotiation would now fail
|
|
1:01:09
|
because udp port 500 is going to be blocked
|
|
1:01:14
|
So if we look at the
|
|
1:01:16
|
look at the ASA, lets make sure that this is applied correctly, lets say show run access list
|
|
1:01:23
|
and show run
|
|
1:01:29
|
show run access group
|
|
1:01:32
|
what I would actually need to say here is I would to flip these port values
|
|
1:01:37
|
I would need to say look for source 500 or destination 500
|
|
1:01:42
|
because I would want to drop the
|
|
1:01:43
|
the negotiation in both directions
|
|
1:01:46
|
So let me add another entry here, we will say access list outside in
|
|
1:01:50
|
is going to deny
|
|
1:01:52
|
any equal
|
|
1:01:54
|
to isakmp or any equal to 500 any
|
|
1:02:00
|
and now on the
|
|
1:02:04
|
now on the vpn client
|
|
1:02:08
|
we should see when we connect
|
|
1:02:12
|
that this is going to be
|
|
1:02:14
|
that this is going to be dropped
|
|
1:02:19
|
if we look at the show connections
|
|
1:02:24
|
says the udp 500 connection is still there, what I may need to do is delete these
|
|
1:02:28
|
lets say clear connections all
|
|
1:02:33
|
and lets turn logging
|
|
1:02:36
|
on for the access list to see if we actually see
|
|
1:02:39
|
these drops
|
|
1:02:42
|
So lets disconnect the tunnel
|
|
1:02:45
|
and we will reconnect it
|
|
1:03:02
|
says we built an outbound udp connection
|
|
1:03:04
|
for the outside that is
|
|
1:03:07
|
200.0.23.3
|
|
1:03:10
|
at port 500
|
|
1:03:12
|
if we look at the show connections
|
|
1:03:15
|
we could see now the udp port 500 is still being allowed
|
|
1:03:19
|
what I actually need to do here because
|
|
1:03:22
|
remember with the ASA's filtering logic
|
|
1:03:24
|
when traffic is moving from the outside in
|
|
1:03:28
|
we are going to check the state table first
|
|
1:03:31
|
before we look at the access list exceptions
|
|
1:03:34
|
So what I actually need to do is, is the reverse of this, we need to say
|
|
1:03:40
|
access list inside in
|
|
1:03:43
|
deny udp any any = 500
|
|
1:03:48
|
then I could say access list inside in
|
|
1:03:51
|
permit everything else, so permit ip any any
|
|
1:03:54
|
and access group
|
|
1:03:56
|
inside in
|
|
1:03:58
|
in interface inside
|
|
1:04:02
|
then was turned logging back on, logging console
|
|
1:04:04
|
7 and logging on
|
|
1:04:08
|
when I now try to start
|
|
1:04:10
|
the tunnel again
|
|
1:04:15
|
So lets disconnects
|
|
1:04:18
|
then reconnect
|
|
1:04:20
|
we could see now the tunnel is being dropped, says deny udp
|
|
1:04:23
|
source from the inside thats going to port 500
|
|
1:04:28
|
So now the firewall is filtering out not only the esp traffic
|
|
1:04:32
|
from coming outside in
|
|
1:04:34
|
but its now stopping the phase I
|
|
1:04:36
|
isakmp negotiation with udp 500
|
|
1:04:42
|
in this particular case
|
|
1:04:44
|
this is where we can use the third option
|
|
1:04:47
|
which is for transparent tunnelling over tcp
|
|
1:04:52
|
where normally our phase I isakmp sa is going to be negotiated using udp port 500
|
|
1:04:59
|
with the cisco proprietary implementation
|
|
1:05:01
|
we can tell it to use a particular tcp port of our choosing
|
|
1:05:05
|
in order to get around that firewall filtering policy
|
|
1:05:10
|
Now we will see this is similar to logic of the SSL
|
|
1:05:14
|
VPNs that runs over tcp port
|
|
1:05:16
|
443
|
|
1:05:19
|
but its still an ipsec vpn
|
|
1:05:22
|
its an ipsec vpn thats using tcp as a transport
|
|
1:05:25
|
as opposed to an ipsec vpn thats using either esp
|
|
1:05:28
|
or using udp for its transport
|
|
1:05:32
|
Now configuration of this
|
|
1:05:34
|
does require some additional steps on the server
|
|
1:05:37
|
very very straight forward though
|
|
1:05:39
|
the only thing we need to do is enable this feature, which is the crypto
|
|
1:05:43
|
TCP
|
|
1:05:46
|
and specify what the port number that we want
|
|
1:05:49
|
where as I mentioned before, the default for this is going to be port 10000
|
|
1:05:55
|
Now on the client
|
|
1:05:58
|
which is the
|
|
1:06:00
|
the windows machine with the vpn client
|
|
1:06:02
|
if we go to modify these parameters for the tunnel
|
|
1:06:06
|
then under the transport tab
|
|
1:06:09
|
we are going to change this
|
|
1:06:11
|
not to use udp for the transparent tunnelling, but to use tcp
|
|
1:06:17
|
we should now see that we could can get around
|
|
1:06:20
|
this udp port 500 filter
|
|
1:06:26
|
the tunnel should establish correctly
|
|
1:06:29
|
and when we actually send the traffic
|
|
1:06:31
|
we should see that we do get the responses back in
|
|
1:06:36
|
but now if we were to go to the ASA and look at the show connections
|
|
1:06:41
|
we see that the inside host
|
|
1:06:44
|
the 192.168.118.100
|
|
1:06:47
|
is now translating to tcp port 10000
|
|
1:06:52
|
as opposed to being translated to either
|
|
1:06:55
|
udp 4500 for the NAT traversal
|
|
1:07:00
|
or the cisco proprietary udp port 10000 that would be used for the ASA
|
|
1:07:05
|
Now we are sending this over tcp
|
|
1:07:12
|
So again in addition to the normal
|
|
1:07:14
|
VPN server configuration on the IOS
|
|
1:07:18
|
you do need to take into account the rest of the design of the topology
|
|
1:07:22
|
to figure out once the tunnel is actually working
|
|
1:07:25
|
do I have any type of filters
|
|
1:07:28
|
that are going to affect the actual transport in data plane
|
|
1:07:33
|
then initially
|
|
1:07:35
|
or additionally we have that problem on router3 of the routing
|
|
1:07:39
|
where when the vpn client connected
|
|
1:07:42
|
we were assigning it an address from the
|
|
1:07:44
|
pool 172.16.255.0
|
|
1:07:48
|
and unless router3 actually has a route back to this
|
|
1:07:52
|
its not going to know where to forward the packet
|
|
1:07:55
|
the way that I solved this in this particular design with
|
|
1:07:58
|
was to simply do a static route on router3
|
|
1:08:02
|
but the other option that we could have
|
|
1:08:03
|
is under the dynamic crypto map
|
|
1:08:09
|
So crypto map dynamic
|
|
1:08:12
|
the name is dynamic map
|
|
1:08:14
|
we could say to inject the reverse route
|
|
1:08:22
|
which then if we were to disconnect
|
|
1:08:25
|
and reconnect the client
|
|
1:08:35
|
if we now take a look at the routing table of router3
|
|
1:08:40
|
and lets undebug all first here
|
|
1:09:02
|
if we now look at the show ip route
|
|
1:09:06
|
we should have the individual host route
|
|
1:09:09
|
for that particular device that
|
|
1:09:12
|
connected to the tunnel
|
|
1:09:15
|
and notice that this static route is pointing towards where the source of the tunnel is coming from
|
|
1:09:20
|
so we are assuming that we already have an address
|
|
1:09:22
|
towards the tunnel peer
|
|
1:09:27
|
then any traffic that is going towards
|
|
1:09:28
|
that peer is likewise going to go inside of the ipsec tunnel
|
|
1:09:33
|
Now notice that since this is a static route
|
|
1:09:36
|
it would then still assume that anyone who is behind the vpn server
|
|
1:09:39
|
is going to need to learn this information somehow
|
|
1:09:42
|
whether we are doing redistribution of static routes into our igp
|
|
1:09:46
|
or may be the devices behind the servers are just doing default routing
|
|
1:09:51
|
we need to make sure that the routing
|
|
1:09:53
|
is solved separately from the tunnel configuration
|
|
1:09:57
|
and then the transport of the tunnel again is going to be another separate issue
|
|
1:10:01
|
So are we running it natively over esp
|
|
1:10:04
|
are we running it over udp over nat reversal
|
|
1:10:08
|
are we running it over udp transparent tunnelling
|
|
1:10:11
|
or we running it over tcp
|
