"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 220.127.116.11 & Loopback0 on the CSR behind ASA4 is 18.104.22.168.
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:
Define Encryption Domain
Create IKEv1 Phase 1 Policy
Create IPsec Phase 2 Policy
Define Connection Profile
Configure Crypto Map
Bind Crypto Map to Interface
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:
Static Crypto Map: identifies peer and traffic to be encrypted explicitly. Typically used to accommodate a few tunnels with different profiles and characteristics.
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!