|
0:00:14
|
In our next section we are going to look at the ASA as the ezVPN server
|
|
0:00:19
|
and the IOS as the ezvpn client
|
|
0:00:22
|
both running in client mode and network extension mode
|
|
0:00:26
|
Now we already have ASA2 configured as the server
|
|
0:00:31
|
the VPN client connection is going to be coming in from router3
|
|
0:00:34
|
ultimately to encrypt traffic that is coming from the 172.16 network
|
|
0:00:38
|
going to the 10 network behind the ASA
|
|
0:00:43
|
on the ASA's command line if we look at the show run crypto
|
|
0:00:48
|
the show run tunnel-group
|
|
0:00:53
|
and the show run group-policy
|
|
0:00:57
|
this is going to show us the full combination of the easyVPN server configuration
|
|
0:01:02
|
where again just like any VPN tunnel, we have
|
|
0:01:05
|
our basic phase I parameters
|
|
0:01:08
|
which is the authentication
|
|
0:01:10
|
the encryption, the hashing and the Diffy Halman group
|
|
0:01:14
|
we then have the phase 1.5 parameters
|
|
0:01:17
|
which are defined by both the tunnel group and the group policy
|
|
0:01:22
|
where the tunnel group is going to define, whats the
|
|
0:01:24
|
username and password
|
|
0:01:27
|
then what is the group policy that is being called
|
|
0:01:30
|
which determines
|
|
0:01:31
|
what is the split tunneling acl
|
|
0:01:34
|
what is the WIN server, what is the DNS server
|
|
0:01:37
|
any of the other options that
|
|
0:01:38
|
that are assigned during the mode configuration
|
|
0:01:42
|
then we have the rest of our phase II options
|
|
0:01:45
|
which are the IPSec transform set
|
|
0:01:49
|
which is then called from the dynamic crypto map
|
|
0:01:52
|
the dynamic crypto map is called from the static crypto map
|
|
0:01:55
|
which is lastly applied on the interface along with ISAKMP
|
|
0:02:01
|
Now currently we have the
|
|
0:02:03
|
the VPN server listing for any connections
|
|
0:02:06
|
which we can see
|
|
0:02:08
|
is the same configuration that were using the connect from the
|
|
0:02:12
|
the software client
|
|
0:02:15
|
so next lets take a look at router3's configuration who is the VPN client
|
|
0:02:21
|
and this is going to be the same configuration as we are going from the
|
|
0:02:24
|
IOS VPN client to the IOS VPN server
|
|
0:02:28
|
where first we need to know what are the inside and the outside interfaces
|
|
0:02:33
|
in this particular case the inside is
|
|
0:02:36
|
is fastethernet0/1
|
|
0:02:38
|
the outside interface is serial1/0.23
|
|
0:02:43
|
and we are going to be encrypting traffic from the inside as it is going to the ASA
|
|
0:02:49
|
next we need to define the
|
|
0:02:51
|
the client configuration
|
|
0:02:53
|
So we say crypto, IPsec client
|
|
0:02:59
|
then whatever the name of this configuration
|
|
0:03:01
|
we will say client1
|
|
0:03:04
|
the most important portion here is
|
|
0:03:06
|
what is the group
|
|
0:03:08
|
username and password
|
|
0:03:10
|
where the ASA define the group username as the test group
|
|
0:03:16
|
the password or the pre shared key
|
|
0:03:19
|
this case is cisco
|
|
0:03:20
|
and then also what is the peer's address
|
|
0:03:23
|
this is going to be the outside interface of the ASA
|
|
0:03:28
|
So 200.0.122.12
|
|
0:03:33
|
we would then define
|
|
0:03:35
|
do you want to automatically connect
|
|
0:03:37
|
or do we want to manually connect
|
|
0:03:39
|
here, I will say we will do a manual connection
|
|
0:03:42
|
then what is the mode
|
|
0:03:43
|
that we are going to run in, we are in client, network extension or network plus
|
|
0:03:48
|
first we are going to look at the client mode
|
|
0:03:52
|
then we have our interfaces, where fastethernet0/1
|
|
0:03:55
|
is the inside
|
|
0:03:59
|
and the serial interface
|
|
0:04:01
|
that is the outside
|
|
0:04:07
|
if we were to go to the ASA and look at the debug
|
|
0:04:10
|
crypto ISAKMP
|
|
0:04:13
|
when we initiate to connection from router3, if we say
|
|
0:04:16
|
crypto
|
|
0:04:18
|
ipsec client ezvpn connect
|
|
0:04:22
|
we should see on the ASA that phase I negotiation occurs
|
|
0:04:27
|
if the router then sees the output
|
|
0:04:29
|
to do extended authenticating
|
|
0:04:31
|
this would then mean that they have agreed on the phase I ISAKMP parameters
|
|
0:04:35
|
and we are now going into the phase 1.5
|
|
0:04:38
|
for mode configuration and extended authentication
|
|
0:04:43
|
so next we authenticate
|
|
0:04:45
|
with the individual username and password
|
|
0:04:48
|
we should now see that the rest of the tunnel negotiates
|
|
0:04:51
|
and that the server is going to
|
|
0:04:54
|
assign an address
|
|
0:04:56
|
since the client was assigned 192.168.0.1
|
|
0:05:01
|
router3 should then assign this to a loopback
|
|
0:05:04
|
and we were then using this for NAT translation, we see this NAT virtual interface changes to up
|
|
0:05:12
|
Now from anyone who is behind the client
|
|
0:05:15
|
lets say for example router4
|
|
0:05:18
|
if we were to send traffic over the tunnel
|
|
0:05:21
|
and to someone behind the server, lets say router6
|
|
0:05:24
|
what we should see
|
|
0:05:26
|
is that the connection is going to come from
|
|
0:05:32
|
the VPN tunnel's address
|
|
0:05:34
|
we telnet into router6 and look at the show users
|
|
0:05:38
|
we see this is coming from the
|
|
0:05:41
|
the tunnel address
|
|
0:05:43
|
that the ASA was assigning down to the client
|
|
0:05:48
|
So the key point of this configuration is that it is no different from the client's point of view
|
|
0:05:53
|
whether we are using the IOS
|
|
0:05:55
|
as the server, or whether we are using the ASA as the server
|
|
0:05:59
|
the only real difference is that, on the server's configuration
|
|
0:06:03
|
we can do
|
|
0:06:04
|
different types of bindings like the ISAKMP profiles
|
|
0:06:07
|
on the IOS
|
|
0:06:08
|
where we are using the tunnel groups and the group policies on the ASA
|
|
0:06:12
|
but from a protocol negotiation point of view
|
|
0:06:15
|
and from an actual transform point of view
|
|
0:06:17
|
they are going to be the identical
|
|
0:06:19
|
the identical result, whether we are using the ASA or whether we are using the IOS
|
|
0:06:26
|
if we were to now go to router3, who again is the client
|
|
0:06:29
|
lets disconnect this, we will say clear crypto
|
|
0:06:32
|
IPSec client
|
|
0:06:38
|
and I am then going to change the
|
|
0:06:41
|
mode, lets show run section crypto
|
|
0:06:44
|
and to change the mode from client
|
|
0:06:47
|
to network extension
|
|
0:06:54
|
so now we are running in network extension mode
|
|
0:06:56
|
I will reinitiate the tunnel
|
|
0:06:59
|
So we say crypto ipsec client ezvpn connect
|
|
0:07:05
|
we should then get our prompt
|
|
0:07:07
|
for extended authentication which we do
|
|
0:07:17
|
if we now connect from router4 to 6
|
|
0:07:27
|
we could see as router6 as not responding
|
|
0:07:29
|
So before we go any further with our troubleshooting on router4
|
|
0:07:33
|
what I am going to do is send packet towards 6
|
|
0:07:43
|
and we will do this with ICMP pings, so we will ping 10.0.6.6
|
|
0:07:48
|
and set a high repeat count
|
|
0:07:53
|
if we then go to router6, and look at the debug IP ICMP
|
|
0:09:50
|
so on router3, if we look at the change in our configuration, we say show run
|
|
0:09:54
|
section crypto
|
|
0:09:57
|
the only thing thats changed here is that we have changed from client mode
|
|
0:10:01
|
to network extension mode
|
|
0:10:04
|
if we then go to connect the
|
|
0:10:07
|
tunnel, we will say crypto
|
|
0:10:10
|
cyrpto ipsec client
|
|
0:10:13
|
ezvpn connect
|
|
0:10:18
|
we should see the option for the
|
|
0:10:20
|
extended authentication, which we do
|
|
0:10:24
|
username is cisco, password is cisco
|
|
0:10:30
|
but it says the connection was terminated
|
|
0:10:36
|
so for some reason
|
|
0:10:38
|
and assuming that this is not a password, username and password authentication problem
|
|
0:10:43
|
but for some option
|
|
0:10:45
|
that is now changed from the client talking to the server
|
|
0:10:49
|
is not accepting our network extension mode request
|
|
0:10:53
|
So before looking at any
|
|
0:10:55
|
anything else on our configuration, lets look at the debug
|
|
0:10:59
|
on the ASA, lets look at the debug
|
|
0:11:03
|
debug crypto ISAKMP
|
|
0:11:09
|
then on router3 lets reinitiate the connection
|
|
0:11:12
|
so crypto ipsec client ezvpn connect
|
|
0:11:25
|
then we have our extended authentication
|
|
0:11:30
|
and it says the connection is terminated
|
|
0:11:32
|
so lets look at the ASA's debug
|
|
0:11:41
|
and I may not be logging at the correct level, lets say login console
|
|
0:11:47
|
logging console 7
|
|
0:12:11
|
So logging console 7, and we know that logging is on
|
|
0:12:14
|
if we show debug
|
|
0:12:16
|
we are debugging ipsec and we are debugging ISAKMP
|
|
0:12:21
|
so now lets reestablish the tunnel
|
|
0:12:25
|
crypto ipsec client ezvpn connect
|
|
0:12:30
|
we should then get our extended authentication request, which we do
|
|
0:12:34
|
username is cisco, password is cisco
|
|
0:12:39
|
then its going to say the connection is terminated
|
|
0:12:41
|
so now on the ASA lets look at
|
|
0:12:43
|
what is the particular reason that its getting
|
|
0:12:46
|
rejected and lets turn logging off, so no logging console
|
|
0:12:53
|
Now based on the fact that I did get request for extended authentication
|
|
0:12:57
|
this should tell us that at a minimum
|
|
0:12:59
|
the phase I negotiation was correct
|
|
0:13:03
|
so if we start at the top, it says
|
|
0:13:05
|
we are trying to start the tunnel
|
|
0:13:08
|
tunnel is coming from router3
|
|
0:13:12
|
we should get the, to the portion where it says
|
|
0:13:17
|
the user authentication is successful
|
|
0:13:21
|
So now we are going to go down into the mode configuration options
|
|
0:13:36
|
it says for this particular tunnel group, which is test group
|
|
0:13:39
|
and the username cisco
|
|
0:13:41
|
the hardware client connection is rejected
|
|
0:13:44
|
because network extension mode is not allowed for this group
|
|
0:13:50
|
So specifically it has to do with the fact now that the hardware client, which is router3
|
|
0:13:55
|
is requesting the network extension mode
|
|
0:13:58
|
and the ASA does not automatically allow this
|
|
0:14:02
|
if we look at the show run all group-policy
|
|
0:14:07
|
on to the group policy
|
|
0:14:10
|
there is a specific field that says, Is network extension mode
|
|
0:14:14
|
enabled or disabled?
|
|
0:14:18
|
so really, this is only going to be
|
|
0:14:21
|
the only functional difference between
|
|
0:14:24
|
the ASA as the server versus the IOS versus the server
|
|
0:14:27
|
when we are using the hardware client
|
|
0:14:30
|
that by default network extension mode disabled on the ASA
|
|
0:14:35
|
Now we can quickly fix this, if we were to say show run
|
|
0:14:38
|
group-policy
|
|
0:14:41
|
and for the group policy that we have for this tunnel
|
|
0:14:44
|
which is vpn client policy 1
|
|
0:14:47
|
we simply need to say that network extension mode is enabled
|
|
0:14:51
|
now if we were to
|
|
0:14:53
|
to re initiate the tunnel from 3
|
|
0:15:02
|
we see we get the request for the extended authentication
|
|
0:15:12
|
it says now the client is up and the network extension mode remote subnets
|
|
0:15:17
|
are 172.16.34.0/24
|
|
0:15:22
|
if we were to now go to router4
|
|
0:15:26
|
which is behind the client side
|
|
0:15:29
|
and send traffic behind the server side
|
|
0:15:34
|
so on router4 if we telnet to router6
|
|
0:15:40
|
again the functional difference here is going to be if we look at the show users
|
|
0:15:44
|
we see that the connection is now coming
|
|
0:15:46
|
from the real internal address
|
|
0:15:49
|
and we do not have a port address
|
|
0:15:51
|
translation occurring on the client
|
|
0:15:58
|
so in the client mode
|
|
0:16:00
|
of IOS, there is nothing different from the ASA as the server
|
|
0:16:04
|
when we are running in network extension mode
|
|
0:16:07
|
we need to account for this that in the group policy this is denied by default
|
|
0:16:13
|
where either we could change it in the group policy that is applied to that individual tunnel group
|
|
0:16:17
|
or we could apply this to the default group policy
|
|
0:16:21
|
which means that it would be inherited by all other group policies
|
|
0:16:25
|
and then in turn by all other tunnel groups
|
