Configuring & Verifying ASA Legacy IKEv1 L2L VPN - CLI

"The What?" - In this post I will cover configuring & verifying a basic site-to-site VPN tunnel between two Cisco ASAs using IKEv1 with pre-shared keys (PSK). These types of VPNs are also known as L2L or lan-to-lan. To see a brief tidbit of comparisons between IKEv1 & IKEv2 see: IKEv1 vs. IKEv2 Tidbit


Also, you can see more about ASAs via the asa tag.


"The Why?" - It is important to understand the differences between legacy ASA L2L VPNs utilizing IKEv1 & how they are constructed versus more modern VPNs utilizing IKEv2.


"The How?" - I want to start with the simple topology used. I have two ASAv devices (ASA3/ASA4) that are connected directly together. The point to point connection is the following on ASA3:

interface GigabitEthernet0/0.300
 vlan 300
 nameif Leg_ike
 security-level 50
 ip address 10.10.30.1 255.255.255.0 

The rest of the interfaces are configured similarly and I have omitted the static routing between all devices to make this work for brevity sake. ASA3 is 30.1 & ASA4 is 30.2. For this blog I will be sharing all config & verification from ASA3. Behind the ASAs I have to CSRs with a loopback0 that will act as the remote LANs for each respective ASA. Loopback0 on the CSR behind ASA3 is 3.3.3.1 & Loopback0 on the CSR behind ASA4 is 4.4.4.1.


Next I will go over the main configuration components. The building blocks for this lab demo consisting of an ASA L2L VPN using IKEv1 with PSK are the following:

  1. Define Encryption Domain

  2. Create IKEv1 Phase 1 Policy

  3. Create IPsec Phase 2 Policy

  4. Define Connection Profile

  5. Configure Crypto Map

  6. Bind Crypto Map to Interface

  7. Enable IKEv1 on Interface

Building Block 1: The encryption domain declares what traffic should be encapsulated within IPsec prior to being sent to peer. Note that all traffic not declared in the ACL is exempt and will be sent in plaintext.


For this demo I will be using both outside interface IPs as the local/remote domains to be encrypted for communication to the respective peer. So declaring the encryption domain is as follows from ASA3:

Note: When creating the ACL to define the encryption domain (interesting traffic) ensure you use an extended ACL otherwise you will get an error when applying it to the crypto map at the end when it comes time to bind everything together.


Building Block 2: Next is the IKEv1 Phase 1 policy configuration consisting of HAGLE. See more about HAGLE here: IKE Phase1 Tidbit - HAGLE

Building Block 3: Now that the IKEv1 policy is configured it is time to focus on phase 2 proposal:

Building Block 4: Next the connection profile needs to get defined. This so called profile essentially defines the properties of how the VPN should operate.

Note that you will see this warning in later versions of code if you attempt to use a name instead of peer IP with IKEv1:

WARNING: For IKEv1, L2L tunnel-groups that have names which are not an IP
address may only be used if the tunnel authentication
method is Digital Certificates and/or The peer is 
configured to use Aggressive Mode

Building Block 5: Now we tie everything together by configuring the crypto map. Brief overview of crypto maps and what they do for us:


Crypto maps are a feature that allows us to bind the previously configured components together. There are two types of crypto maps:

  1. Static Crypto Map: identifies peer and traffic to be encrypted explicitly. Typically used to accommodate a few tunnels with different profiles and characteristics.

  2. Dynamic Crypto Map: is one of the ways to accommodate peers sharing same characteristics (for example multiple branches offices sharing same configuration)

Lastly, here are a few important tidbits on crypto maps:

  • One crypto map can be applied to an interface

  • Same crypto map can be applied to multiple interfaces

  • To accommodate multiple tunnels crypto map entries are used. One crypto map can have multiple entries, identified by a sequence number.

  • Static crypto map can reference a dynamic crypto map.

Here is the configuration example I used:

Building Block 6 & 7: At this point the heavy lifting is done. The last two configuration blocks are straight forward. We bind the crypto map to interface & enable IKEv1 on the interface.

All configuration is similar on the remote peer (ASA4).


Now let's breakdown & cover verifying the IKEv1 L2L VPN:

*Note all interesting traffic was generated from the CSR behind ASA3.

#show crypto isakmp sa
#show crypto ikev1 sa
#show crypto ikev1 stats

Notable debug commands:

#debug crypto ikev1 127 --(Phase 1)

To summarize IKEv1 Phase 1 goals:

  • Establishes secure connection

  • Exchanging 'key material'

  • Keys used for encryption and hashing

Lastly, to gain a better understanding of IKEv1 status messages/states & debugging see: Debugging IKEv1 on ASA


That wraps up this post covering deploying an IKEv1 L2L VPN on ASA via CLI. Cheers!

0 comments

Recent Posts

See All

Debugging IKEv1 on ASA

In the post I want to cover understanding IKEv1 status messages & debugging IKEv1 main mode. It is important as each message has its own unique meaning, and these messages are typically seen when att

Understanding ASA AnyConnect Webdeploy

In this post I want to cover the components & general understanding of how the ASA AnyConnect (AC) Webdeploy process works. First, it is important to understand that the AnyConnect client on an end no