Configuring IPSEC VPN with Cisco ASA

Version: 1.5

Created for: Cisco Learning Network

Author: Jrgen Ilse

net.DE AG
http://www.net.de/
Bttnerstr. 57
30165 Hannover
Germany

creation date February 17. 2016

Last changed March 8. 2016
Configuring IPSEC VPN with Cisco ASA

This Document was created, to help the readers to configure IPSEC VPN with Cisco ASA as VPN endpoint.

List of changes
Date Version Author description Status
February 17. 2016 1.0 Jrgen Ilse Document created draft
February 17. 2016 1.1 Jrgen Ilse Corrected 2 little errors draft
February 19. 2016 1.2 Jrgen Ilse Reformatted and revised the text draft
February 21. 2016 1.3 Jrgen Ilse Corrected typing errors, added hea- draft
ding line to 3.5
February 21. 2016 1.4 Jrgen Ilse Added section about ASA5505 as draft
eazy VPN hardwareclient
March 8. 2016 1.5 Jrgen Ilse Added URL, changed eazy VPN to draft
EZ VPN and some changes in 3.6

February 19.2016 Configuring IPSEC VPN with Cisco ASA page: 2 / 10

Configuring IPSEC VPN with Cisco ASA

Table of content

1 Preface............................................................................................................................................. 4
2 Phase 1? phase 2? What is it?....................................................................................................... 4
2.1 Phase 1..................................................................................................................................... 4
2.2 Phase 2..................................................................................................................................... 4
3 Now for real examples.................................................................................................................... 5
3.1 Most simple case: Lan-to-Lan VPN with static endpoints and IKEv1.........................................5
3.2 Lan-to-Lan VPN with static endpoints and IKEv2......................................................................6
3.3 IKEv1 VPN with one dynamic endpoint.....................................................................................7
3.4 IKEv2 VPN with one dynamic endpoint.....................................................................................8
3.5 IKEv1 remote access VPN with xauth.......................................................................................9
3.6 ASA 5505 as EZ VPN hardwareclient........................................................................................ 9

February 19.2016 Configuring IPSEC VPN with Cisco ASA page: 3 / 10

Configuring IPSEC VPN with Cisco ASA

1 Preface
This document will show only the use of pre-shared-keys for authentication, because that is the most
simple possibility and the most used possibility, as it will be supported on nearly every device that is
capable of terminating an IPSEC tunnel. Maybe the use of certificates for authentication will be
added in a later version of this document, but for now, I will only show the use of pre-shared-keys for
authentication.
This document will show IKEv1 and IKEv2 configurations (I think, IKEv1 is most used these days, but
IKEv2 has several advantages, so it supports IPv6 transport over IPSEC, which is, as far as I know,
not supported with IKEv1). It will also show the possibility to create Lan-to-Lan VPNs with one dy -
namic endpoint and remote access VPNs (the latter only for IKEv1 VPNs for now, as I didnt tried to
use IKEv2 with remote access VPNs until now).
This document will only explain configuration of IPSEC VPN with Cisco ASA. It will not explain the
cryptographic fundamentals. This document will only show tunnel mode, as transport mode is not
as often used as tunnel mode.

2 Phase 1? phase 2? What is it?

2.1 Phase 1

Simply speaking, phase 1 of an IPSEC VPN is something like discussing IPSEC policy with the
peer, authentication of the peer and exchanging session keys for encryption. These functions will be
implemented with IKE (Internet Key Exchange) protocol. IKE is a combination different protocols:
ISAKMP, OAKLEY and SKEME. I will not describe those protocols in more detail here. If you want a
more detailed description of IKE, you may look at other sources.
There are two versions of IKE protocol. The first version (IKEv1) is described in RFC2407, RFC2408
and RFC2409. The second version of IKE (IKEv2) was first published as RFC4306 in december
2005. Some open details were clarified with publication of RFC4718 in october 2006, and these 2
documents (and a few more clarifications) were combined into the updated IKEv2 RFC5996 in sep-
tember 2010 as a proposed internet standard. This proposed standard was updated to an internet
standard in october 2014 with RFC7296.
As you can see in these list of evolution of IKEv2, the standard of IKEv2 is really new compared
with other internet standards, that we use every day. Maybe that is the reason, why it is used less of -
ten than IKEv1 these days. With IKE the key-exchange will be done with asymmetric cryptographie
(with both versions: IKEv1 and IKEv2), the keys for phase 2 will be symmetric keys, because sym-
metric cryptographie needs less resources and can be done faster.

2.2 Phase 2

In phase 2, the communication via IPSEC takes place. This communication will be (as stated above)
encrypted using symmetric cryptography. In phase1, there were build two security-associations
(SA) for the traffic transferred in phase 2 for every combination of hosts or networks, which will com -
municate with each other. With Cisco ASA, the traffic that should be encrypted will be declared with
an access-list. As a simple rule, you can remember, that there will be two SAs created for every entry
in the (expanded) access-list.
Cisco ASA supports (according to the documentation) the use of extended access-lists, that restrict
IPSEC traffic between two hosts or networks to specific protocols, but that is (as far as i know) a
cisco-proprietary extension, so i would not use such a configuration until it is really necessary (and
for me, it was never really necessary until now ).

February 19.2016 Configuring IPSEC VPN with Cisco ASA page: 4 / 10

Configuring IPSEC VPN with Cisco ASA

Before you ask, why two SAs will be created for every combination of hosts or networks, that need to
communicate with each other, let me explain. There is one SA per direction: one outgoing SA for out -
going traffic from the ASA to the remote device and one incoming SA for traffic send by the remote
device to our ASA. The ACL defining the IPSEC traffic defines only the outgoing traffic. The ASA will
build the SAs only, if the entries of these two SAs will match (so that all answer traffic for traffic sent
out encrypted will be received encrypted via the corresponding incoming SA).
SAs will be opened only when needed, i.e. when there is traffic to be send via that SA (but normally,
when an outgoing SA is opened, the corresponding incoming SA will be opened as well).
Traffic, that will be received unencrypted while matched by an incoming security SA will be dropped
by the ASA. This will make the use of the packet-tracer utility builtin in ASA firmware difficult for inco -
ming traffic received via IPSEC: packet-tracer cant inject encrypted traffic, so in this case, packet-
tracer will always say, that the packet is dropped due to IPSEC spoofing (you can only trust the
steps listed until VPN in this case).

3 Now for real examples

3.1 Most simple case: Lan-to-Lan VPN with static endpoints and IKEv1
The most simple IPSEC VPN will be a Lan-to-Lan VPN with static endpoints and IKEv1. So what is
the minimum configuration for that? We need at least an IKEv1 policy that defines authentication me-
thod, encryption method, hash function and lifetime for phase 1.
You may have different IKEv1 policies configured. Each IKEv1 policy has a sequence number, and
the ASA will try to find an IKEv1 policy, that will be accepted by the remote device. The policies will
be tried in the order of ascending sequence numbers. The ASA will use the first matching IKEv1 poli-
cy. The IKEv1 protocol has to be enabled on the interface on which the IPSEC tunnel will terminate.
Next we need a crypto map bound to the same interface. The crypto map may contain entries for se-
veral VPN peers. The entries for the same VPN have all the same sequence number, entries for dif-
ferent VPNs have different sequence numbers.
The minimum entries that are required for a VPN peer coonsist of a match statement containing the
name of an access-list defining the outgoing traffic for this VPN, a set peer statement defining the
IP address of the VPN peer and an entry that determines the IKEv1 transform-set (that has to be
defined before). This transform-set defines the algorithms used for phase 2.
Next we need to define the tunnel-group for this VPN peer. Per default, ASA uses the IP-adddress as
identity for the IPSEC VPN if pre-shared keys are used for authentication and the DN from the cer -
tificate as identity for certificate based authentication.
These identities are used with isakmp identity auto which is default. You may advice the ASA to
always use the IP address as identity with the configuration line isakmp identity address or you can
choose to use a string as key identifier for the identity of the ASA with isakmp identity key-id
<string>.
The isakmp identity setting is a global configuration with cisco ASA, so you cant use identity ad-
dress for one tunnel with pre-shared-key authentication and identity hostname for another tunnel
with pre-shared-key authentication. If i remember correctly, IOS will permit to use different isakmp
identity settings for any peer, but with ASA, the isakmp identity setting is global.
So the minimum configuration for such an IPSEC VPN may look like this:

access-list mytunnel permit ip host x.x.x.x host y.y.y.y

crypto ipsec ikev1 transform-set myset esp-aes esp-sha-hmac
crypto ikev1 enable outside
crypto ikev1 policy 10
authentication pre-share
encryption aes-256
hash sha
group 2
lifetime 86400
crypto map mymap 10 match address mytunnel

February 19.2016 Configuring IPSEC VPN with Cisco ASA page: 5 / 10

Configuring IPSEC VPN with Cisco ASA

crypto map mymap 10 set peer z.z.z.z

crypto map mymap 10 set ikev1 transform-set myset
crypto map mymap interface outside
tunnel-group z.z.z.z type ipsec-l2l
tunnel.group z.z.z.z ipsec-attributes
ikev1 pre-shared-key *****

This is really the minimum configuration that is necessary for such a VPN configuration. In that confi-
guration snippet, the entry group 2 in the IKEv1 policy means Diffie Hellman group 2 for the phase
1 communication. For further information about different DH-groups, you may consult other sources
of information. As i stated above, this document is only about configuration of IPSEC VPN and will
not provide information about the mathematics behind that all.
The lifetime in the IKEv1 policy is the lifetime for phase1. When this lifetime expires, the IKEv1 nego-
tiation will start again. The transform-set in this example uses aes128 for encryption (aes does al-
ways mean aes128 with cisco ASA, the other aes algorithms are called aes192 and aes256) and
SHA1 as hash function (the other supported hash function for use with IKEv1 on Cisco ASA is md5).
ASA does not support AH, so one has always to use ESP for IPSEC VPN. Note that the access-list
in the match statement of the crypto map should only contain IPv4 entries for IKEv1 VPNs, because
transport of IPv6 is not supported with IKEv1 VPNs.
There are some further options you may add to this minimal configuration. As this is only a document
describing the basics of IPSEC VPN configuration on ASA, you may look at Cisco documentation for
more information about that other options.
For phase 2, you may set pfs (crypto map mymap set pfs group5). PFS (perfect forward secrecy) is
a method to disable the reconstruction of the session key used in phase 2 from a recording of the
complete communication after the session has ended (even if later on the private keys used in phase
1 will be known). If you set pfs but do not specify a DH-group for pfs, group2 will be used as default.
You may also add lifetimes in seconds and in kilobytes to the crypto map (when the SA is up for this
time or when there was transferred that amount of data via that SA, the ASA will restart phase 2 ne -
gotiation for that SA to select a new session key). The defaut values for phase 2 lifetimes are 28800
seconds (8 hours) and 4608000 kilobytes. These global defaults may be overridden with the global
configuration option crypto ipsec security-association lifetime xxx seconds yyy kilobytes. You can
also override these defaults per crypto map entry with crypto map mymap set security-association li-
fetime ....
There are some more global options for IPSEC VPN, for example crypto isakmp disconnect-notify,
isakmp keepalives or crypto isakmp nat-traversal <seconds> or set reverse-route which enables
the redistribution for the tunnel-routes via routing protocols (the default is disabling redistribution of
the IPSEC tunnel-routes) and a few more options. But these are not necessary for a functional IKEv1
IPSEC configuration.If you want to learn more about these options, use the cisco documentation.

3.2 Lan-to-Lan VPN with static endpoints and IKEv2

This case is very similar to the IKEv1 VPN as described above, but the IKEv1 transform-set will be
replaced with an ikev2 ipsec-proposal and the IKEv2 policy is replaced with an IKEv2 policy. To use
IKEv2 VPNs, you have to enable IKEv2 on the outgoing interface for the VPN traffic.
The IKEv2 ipsec-proposal has a different syntax than the ipsec IKEv1 transform-set, but it contains
similar data. The ikev2 policy is also very similar to the IKEv1 policy, except, that instead of hash
sha|md5 you use the statements integrity <hashfunction> and prf <hashfunction (the first for inte -
grity algorithm, the second as hash algorithm). The supported hashfunctions do not only include md5
and sha1 as with IKEv1, but also sha256, sha384 and sha512.
While with IKEv1 you specify only one pre-shared key for authentication, you can use different au-
thentication for local and remote sides. That means, you may specify different IKEv2 pre-shared-
keys for local authentication and remote authentication in the tunnel-group. You may also use diffe-
rent authentication methods for local and remote authentication, but i will not show an example for
that in this document, because (as i stated before) i will only show authentication with pre-shared-
keys in this document.

February 19.2016 Configuring IPSEC VPN with Cisco ASA page: 6 / 10

Configuring IPSEC VPN with Cisco ASA

In the IKEv2 policy, there is no authentication pre-share because the local and remote authenticati-
on methods are specifies in the tunnel-group ipsec-attributes. So lets look at an example of IKEv2
VPN configuration:
access-list extended mytunnel permit ip host x.x.x.x host y.y.y.y
access-list extended mytunnel permit ip x:x:x:x::/64 y:y:y:y::/64
crypto ipsec ikev2 ipsec-proposal myprop
protocol esp encryption 3des
protocol esp integrity sha-1
crypto ikev2 policy 10
encryption aes-256
integrity sha
group 24
prf sha
lifetime seconds 86400
crypto ikev2 enable outside
crypto map mymap 10 match address mytunnel
crypto map mymap 10 set peer z.z.z.z
crypto map mymap 10 set ikev2 ipsec-proposal myprop
crypto map mymap interface outside
tunnel-group z.z.z.z type ipsec-l2l
tunnel-group z.z.z.z ipsec-attributes
ikev2 remote-authentication pre-shared-key *****
ikev2 local-authentication pre-shared-key *****

So its not really so much more complicated as IKEv1 VPN, but many admins (including me) have re-
siled for IKEv2 VPN configurations, because they havent yet configured this kind of VPN and it looks
unfamiliar. I used IKEv2 the first time, when i had the need to create a VPN, that transports IPv4 and
IPv6. As you can see here, the only change necessary for an IKEv2 VPN to transport IPv4 and IPv6
is adding IPv6 ACL rules to the access-list that defines the tunnel traffic. After i learned, that IKEv2 is
not really much more complicated than IKEv1, i will more often think about using IKEv2 instead of
IKEv1. Hopefully this would also apply to you after reading this document

3.3 IKEv1 VPN with one dynamic endpoint

The configuration of the side with dynamic IP address is similar to the configuration as listed in secti -
on 3.1 (the remote side has static IP address, so its really the same as in 3.1). So lets talk about the
configuration on the side with static ip address. In this configuration, we dont know the IP address of
the remote device, so we cant configure the (necessary) peer IP address in the crypto map.
For this kind of configuration, there is the possibility of dynamic-maps. A crypto dynamic-map is
an incomplete crypto map, that is lacking the peer address (and maybe the match statement). You
can include that dynamic-map in the crypto map bound to an interface of the ASA.
You should include that dynamic map with the highest sequence number, because the ASA will choo -
se the first matching entry from the crypto map, and because the dynamic-map matches every remo -
te ip address, so the crypto map entries behind the dynamic map (if there are any) will never be rea-
ched.
Also you cant configure a tunnelgroup with the remote IP address as name, because you dont know
the remote IP address of the remote device with dynamic IP address. For this purpose, there exists
two special tunnel-groups (one for Lan-to-Lan VPNs and one for remote-access VPNs) on which all
connections land, that will not match any other tunnel-group. The name of this special tunnel-group
for Lan-to-Lan VPNs is DefaultL2Lgroup. So the complete configuration may look like this:

group-policy my-L2L-ikev1 internal

group-policy my-L2L-ikev1 attributes
vpn-tunnel-protocol ikev1
crypto ipsec ikev1 transform-set myset esp-aes esp-sha-hmac
crypto ikev1 enable outside
crypto ikev1 policy 10
authentication pre-share
encryption aes
hash md5
group 2
lifetime 86400
crypto dynamic-map mydynmap 1 set ikev1 transform-set myset
crypto map mymap 999 ipsec-isakmp dynamic mydynmap
crypto map mymap interface outside
tunnel-group DefaultL2Lgroup type ipsec-l2l

February 19.2016 Configuring IPSEC VPN with Cisco ASA page: 7 / 10

Configuring IPSEC VPN with Cisco ASA

tunnel-group DefaultL2Lgroup general-attributes

default-group-policy my-L2L-ikev
tunnel.group DefaultL2Lgroup ipsec-attributes
ikev1 pre-shared-key *****

Note, that with this configuration, all dynamic peers have to use the same pre-shared-key, as they all
land on tunnel-group DefaultL2Lgroup, and so they all must use the same PSK as configured for the
DefaultL2Lgroup tunnel-group. The rest of the configuration is the same as in section 3.1, the only
difference is the use of a dynamic-map entry instead of the normal complete crypto map entry.
You may set additional options for the dynamic-map, for example crypto dynamic-map mydynmap 1
set reverse-route or crypto dynamic-map mydynmap 1 set pfs group5.
Be careful with this kind of configuration, as with dynamic remote IP address and authentication with
pre-shared-key is only possible with aggressive mode, not with main mode. Aggressive mode could
be a security risk, if someone succeeds with being a man in the middle of the connection. Better
use IKEv2 VPN with dynamic endpoints and PSK or IKEv1 VPN with certificate authentication whe-
never possible (with certificate based authentication, the identity of the remote device can be
checking the certificate, so man in the middle attacks will be made impossible).

3.4 IKEv2 VPN with one dynamic endpoint

With this case, we have also to use a dynamic-map, as the remote IP address is unknown. We can
use the tunnel-group DefaultL2Lgroup similar to section 3.3 of this document, but there is another
possibility.
If we use crypto isakmp identity hostname on the ASA with dynamic IP address, we can configure a
tunnel-group with the same name as the remote FQDN on the ASA with the static IP address, and
the VPN connection will land on that tunnel-group. I have tried that also with IKEv1, but i was not
successful, so with IKEv1 i had to use the DefaultL2Lgroup tunnel-group (maybe that is only an issue
with an ASA as device with the dynamic IP address).
But lets have a look at the configuration with IKEv2 now. It is very similar to the configuration in 3.2,
except. That we use again a dynamic-map as in 3.3 and the name of the tunnel-group is now the
FQDN configured on the remote ASA with dynamic IP address instead of the IP address of the remo-
te device.
group-policy my-L2L-ikev2 internal
group-policy my-L2L-ikev2 attributes
vpn-tunnel-protocol ikev2
crypto ipsec ikev2 ipsec-proposal myprop
protocol esp encryption 3des
protocol esp integrity sha-1
crypto ikev2 policy 10
encryption aes-192
integrity sha
group 24
prf sha
lifetime seconds 86400
crypto ikev2 enable outside
crypto dynamic-map mydynmap 1 set ikev2 ipsec-proposal myprop
crypto map mymap 999 ipsec-isakmp dynamic mydynmap
crypto map mymap interface outside
tunnel-group remotehost.domain.com type ipsec-l2l
tunnel-group remotehost.domain.com general-attributes
default-group-policy my-L2L-ikev2
tunnel-group remotehost.domain.com ipsec-attributes
ikev2 remote-authentication pre-shared-key *****
ikev2 local-authentication pre-shared-key *****

In this configuration, you may also set additional options as mentioned in section 3.3. For more in -
formation of possible additional configuration options, consult the cisco documentation.
I think with all the examples until now (IKEv1, IKEv2, with static and with dynamic remote endpoint),
it is no need to explain more for this configuration, as nearly all of the configuration options can be
found in one of the other sections (but not in this special combination).

February 19.2016 Configuring IPSEC VPN with Cisco ASA page: 8 / 10

Configuring IPSEC VPN with Cisco ASA

3.5 IKEv1 remote access VPN with xauth

The remote access VPN uses also a dynamic-map, because we also dont know the remote IP ad-
dress of the VPN-client. The difference to 3.3 and 3.4 ist, that we can configure the name of the tun-
nel-group in the VPN-client, we will receive in a typically configuration an IP-address for the VPN-cli-
ent from a pool configured on the ASA and we will receive information about the split-tunnel policy
from the remote device.
Also we will mormally use xauth which means, that we use additional authentication with the local
username and a user-specific password (if an aaa-server is defined, we can also use accounts fron
this aaa-server, if we add authentication-server-group <name_of_aaa-server-group> to the general-
attributes of the tunnel-group). Here is an example of such a configuration (with local configured VPN
users):
ip local pool MY-POOL 192.168.1.0-192.168.0.255 mask 255.255.255.255
group-policy my-ra-policy internal
group-policy my-ra-policy attributes
vpn-tunnel-protocol ikev1 ssl-client
split-tunnel-policy tunnelall
address-pools value MY-POOL
dns-server value 10.2.11.74 10.2.11.76
wins-server value 10.2.11.74 10.2.11.76
tunnel-group my-ra-group type remote-access
tunnel-group my-ra-group general-attributes
default-group-policy my-ra-policy
tunnel-group my-ra-group ipsec-attributes
ikev1 pre-shared-key *****
username myuser password mysecretpasswd privilege 0

Some options in the group-policy (dns-server, wins-server) are optional in this configuration. As VPN-
client for this configured remote-access VPN you may use the shrewsoft VPN-client (which is free of
charge and can be downloaded from http://www.shrew.net/). The cisco ipsec-client is not supported
anymore (cisco suggests to use sslvpn with anyconnect client for remote access VPN).
I have here only used pre-shared-key with xauth for authentication (as stated in the preface of this
document). It is recommended to use hybrid authentication with xauth, because in that configuration,
the ASA will authenticate itself to the client with a certificate and so man-in-the middle attacks to the
VPN connection are impossible in that case until the private key fron the certificate is known by the
attacker.
I have done this configuration without hybrid authentication, to avoid explaining use of certificates on
the ASA (it want to finish tis document without beginning a new chapter about use of certificates wi -
thin ASA configuration, maybe i will add that in a future version of this document ).
I hope, that you find this document helpful, and maybe it will help you to use IKEv2 VPN (which can
also transport IPv6, not only IPv4, and which uses a better protocol for phase1 communication) ins -
tead of IKEv1 VPN. Comments to this document are welcome.

3.6 ASA 5505 as EZ VPN hardwareclient

The answer to this question is (at least for one side of the connection) No it isnt. So what is the
simpler possibility to create an IPSEC VPN with Cisco ASA? Its the configuration of the ASA as
eazy VPN hardwareclient. What we need before we can use the ASA as EZ VPN hardwareclient,
is the configuration of the server side.
Only ASA5505 can be used as EZ VPN hardwareclient, other models are not supported.
All we have to do for this is already in this document. Its simply the configuration of a remote access
VPN as it is shown in section 3.5. So now for the client side. I wrote, it would be easier than all pos-
sibilities explained above, so judge for yourself:
vpnclient server x.x.x.x
vpnclient vpngroup my-vpngroup password *****
vpnclient username myusername password *****
vpnclient enable

February 19.2016 Configuring IPSEC VPN with Cisco ASA page: 9 / 10

Configuring IPSEC VPN with Cisco ASA

Yes, thats it. It is really that simple. The ASA gets an IP-address from the configured IP pool on the
server side and all vpn traffic through this tunnel will be natted behind the IP address assigned for
the hardwareclient from the server side. Also other properties of the VPN configuration (like split-tun-
nel-policy) will be configured at the server-side. Please note, that Diffie-Hellman group2 is required in
ikev1 profile on the server side for EZ VPN hardwareclients. The hardwareclient does not need
more configuration as IP-address of server, vpn-group and pre-shared-key as well as xauth userna-
me and password, nothing more than you will configure for a VPN session with a VPN client.
But because of the implicit natting, you have no chance to access the inside network of the hardwa-
reclient from server side of this VPN connection. What if you need to access the system behind the
EZ VPN hardwareclient? Is there a possibility for that too?
I asked, if there is also a possibility with the ASA as EZ VPN hardwareclient, where we can access
the network behind the inside interface of an EZ VPN hardwareclient. The answer to this question is
yes and the solution is called nem (network extension mode).
The configuration is very similar to the EZ VPN client configuration above. but there is one difference
on the server side and a few differences on the client. On the server side, we have to add the option
nem enable to the group-policy on the server side. That are all needed changes on the server side.
And now for the client side (which is limited to ASA5505, as other ASA models are not supported as
EZ VPN hardwareclient). In addition to the client configuration listed above, we need to set the option
vpnclient mode network-extension-mode. Also we need to disallow the natting, that will be used
otherwise with an identity nat rule for the inside network.
object network inside_network
subnet 192.168.0.0 255.255.255.0
nat (inside,outside) source static inside_network inside_network
!
vpnclient server x.x.x.x
vpnclient vpngroup my-vpngroup password *****
vpnclient username myusername password *****
vpnclient mode network-extension-mode
vpnclient nem-st-autoconnect
vpnclient enable

As you see here, i have used an additional option vpnclient nem-st-autoconnect, which is nothing
else than always on configuration for this VPN (which is maybe what you want to use, if you want to
use network-extension-mode).
But where do we see, what network behind the hardwareclient ASA will be available through this tun-
nel? The EZ VPN hardwareclient feature of ASA5505 supports only the use of the network directly
connected to the interface with the highest security level.
That needs less configuration (as we do not need to specify the network from which the traffic will
run through the VPN), but its also a limitation. If you can live with this limitation and you have an
ASA5505, the configuration as EZ VPN hardwareclient (with or without network-extension-mode)
is possibly the most simple VPN solution available to connect networks from a branch offices to the
central office.

February 19.2016 Configuring IPSEC VPN with Cisco ASA page: 10 / 10