(Legacy Guide) ASA 8.4 Site-to-Site VPN Tunnel using IKEv1

Important Security Warning: Legacy Content

This guide was originally published in 2013 and details the configuration of a VPN using technologies that are now obsolete and insecure. Cisco ASA 8.4 is End-of-Life, and protocols like IKEv1, 3DES, MD5, and DH Group 2 have critical vulnerabilities.

This configuration should NOT be used in a modern production network. This article is maintained for archival and educational purposes for those managing legacy systems. For current security standards, please see our modern guide:

How to Configure a Secure Site-to-Site VPN on Cisco Firepower (IKEv2, AES-256)

ASA 8.4 Site to Site VPN Tunnel using ikev1 between ASA and Cisco Router

We will be working on the above-mentioned topology on GNS3. Our goal is to configure a legacy site-to-site (S2S) VPN tunnel between an Arizona ASA1 running code 8.4 and a Nevada router. Finally, we will allow our LAN subnets of both locations to communicate across the VPN tunnel. IP addressing is mentioned in the diagram.

Initial Configuration Verification

Before starting with the S2S VPN configuration, let’s verify the basic interface and access-list configuration of the ASA.

ASA1# sh run int g0
interface GigabitEthernet0
 nameif inside
 security-level 100
 ip address 10.10.10.1 255.255.255.0
ASA1# sh run int g1
interface GigabitEthernet1
 nameif outside
 security-level 0
 ip address 12.12.12.1 255.255.255.0

For lab purposes, I have created overly permissive access lists. This should never be done in a production network.

ASA1# sh run access-list
access-list outside_in extended permit ip any any
access-list inside_in extended permit ip any any
access-list interesting-traffic extended permit ip 10.10.10.0 255.255.255.0 20.20.20.0 255.255.255.0
ASA1# sh run access-group
access-group inside_in in interface inside
access-group inside_in out interface inside
access-group outside_in in interface outside
access-group outside_in out interface outside

Now we will begin configuring the S2S VPN tunnel on ASA1 using the legacy IKEv1 protocol. I will highlight every step as we move forward.

Configuring Legacy ISAKMP Policies (IKEv1 Phase 1)

Step 1: Enter IPsec IKEv1 policy configuration mode.

ASA1(config)# crypto ikev1 policy 1
ASA1(config-ikev1-policy)#

Step 2: Set the authentication method to a pre-shared key.

ASA1(config-ikev1-policy)# authentication pre-share
ASA1(config-ikev1-policy)#

Step 3: Set the encryption method. This example uses 3DES.

ASA1(config-ikev1-policy)# encryption 3des
ASA1(config-ikev1-policy)#

Security Note: 3DES is a weak and deprecated encryption algorithm. Modern security standards require using AES, preferably AES-256.

Step 4: Set the HMAC method. This example uses MD5.

ASA1(config-ikev1-policy)# hash md5
ASA1(config-ikev1-policy)#

Security Note: MD5 is cryptographically broken and should not be used. Secure networks must use SHA-256 or a stronger hashing algorithm.

Step 5: Set the Diffie-Hellman group. This example uses Group 2.

ASA1(config-ikev1-policy)# group 2
ASA1(config-ikev1-policy)#

Security Note: DH Group 2 (1024-bit) is considered weak and vulnerable to attacks. Modern standards require using Group 14 or higher, with Group 19, 20, or 21 recommended.

Step 6: Set the encryption key lifetime. The following example configures 43,200 seconds (12 hours).

ASA1(config-ikev1-policy)# lifetime 43200
ASA1(config-ikev1-policy)#

Step 7: Enable IKEv1 on the outside interface and save the configuration.

ASA1(config)# crypto ikev1 enable outside
ASA1(config)# write memory

Creating an IKEv1 Transform Set (IKEv1 Phase 2)

An IKEv1 transform set combines an encryption method and an authentication method. During the IPsec security association negotiation, the peers agree to use a particular transform set to protect a specific data flow. The transform set must be the same for both peers.

Step 1: In global configuration mode, define the transform set. This example creates a set named CRYPTO_SET using esp-3des encryption and esp-md5-hmac authentication.

crypto ipsec ikev1 transform-set transform-set-name encryption-method authentication-method

ASA1(config)# crypto ipsec transform-set CRYPTO_SET esp-3des esp-md5-hmac
ASA1(config)#

Configuring the VPN Traffic ACL

Step 1: Create an access control list (ACL) that defines the “interesting traffic” to be encrypted. This ACL should permit traffic from your local LAN to the remote LAN.

ASA1(config)# access-list interesting-traffic extended permit ip 10.10.10.0 255.255.255.0 20.20.20.0 255.255.255.0

Defining a Tunnel Group

A tunnel group is a set of records that contain tunnel connection policies. For a LAN-to-LAN VPN, it defines the connection type and pre-shared key for a specific peer.

Step 1: Create the tunnel group, specifying the peer’s public IP address and setting the connection type to LAN-to-LAN (ipsec-l2l).

ASA1(config)# tunnel-group 34.34.34.1 type ipsec-l2l
ASA1(config)#

Step 2: Enter the ipsec-attributes sub-mode and define the IKEv1 pre-shared key. This key must match exactly on the remote peer.

ASA1(config)# tunnel-group 34.34.34.1 ipsec-attributes
ASA1(config-tunnel-ipsec)# pre-shared-key cisco

Creating and Applying a Crypto Map

The crypto map ties all the previous elements together: the traffic to encrypt (ACL), the peer to connect to, and the security parameters (transform set).

Step 1: Assign the ACL to a crypto map entry.

ASA1(config)# crypto map IPSEC 1 match address interesting-traffic
ASA1(config)#

Step 2: Identify the peer for this IPsec connection.

ASA1(config)# crypto map IPSEC 1 set peer 34.34.34.1
ASA1(config)#

Step 3: Specify the IKEv1 transform set for the crypto map entry.

ASA1(config)# crypto map IPSEC 1 set ikev1 transform-set CRYPTO_SET
ASA1(config)#

Step 4: Apply the crypto map to the outside-facing interface.

ASA1(config)# crypto map IPSEC interface outside

Nevada Router Configuration

The remote router configuration is straightforward. The encryption, hash, and group parameters must match the ASA’s configuration for the tunnel to establish correctly.

Nevada#sh run | s crypto
crypto isakmp policy 1
 encr 3des
 hash md5
 authentication pre-share
 group 2
 lifetime 43200
crypto isakmp key cisco address 12.12.12.1
crypto ipsec transform-set CRYPTO esp-3des esp-md5-hmac
crypto map IPSEC 1 ipsec-isakmp
 set peer 12.12.12.1
 set transform-set CRYPTO
 match address 101

The ACL on the router must be a mirror image of the ASA’s interesting traffic ACL.

Nevada#sh run | i access-list
access-list 101 permit ip 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255

Finally, apply the crypto map to the outside interface of the Nevada router.

Nevada#sh run int fa0/1
 ip address 34.34.34.1 255.255.255.0
 duplex auto
 speed auto
 crypto map IPSEC
end

Testing and Verifying the Tunnel

After configuring both sides, we must initiate traffic from one LAN to the other to build the tunnel. Let’s send a ping from the Nevada LAN to the Arizona LAN.

NevadaLAN#ping 10.10.10.2 re 10

Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 32/69/104 ms

And now from the Arizona LAN to the Nevada LAN:

ArizonaLAN#ping 20.20.20.2 re 10

Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 20.20.20.2, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 40/65/108 ms

Now we can verify the tunnel status with a few show commands. On the ASA, check the IKEv1 Phase 1 Security Association (SA).

ASA1# sh crypto isakmp sa

IKEv1 SAs:

   Active SA: 1
   Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1   IKE Peer: 34.34.34.1
    Type    : L2L           Role    : responder
    Rekey   : no            State   : MM_ACTIVE

And on the Nevada router:

Nevada#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state           conn-id slot status
12.12.12.1      34.34.34.1      QM_IDLE            1003    0 ACTIVE

Indeed, our tunnel is up and working. Let’s now verify packet encapsulation and decapsulation on the ASA to see traffic flowing through the tunnel.

ASA1# sh crypto ipsec sa
interface: outside
    Crypto map tag: IPSEC, seq num: 1, local addr: 12.12.12.1

      access-list interesting-traffic extended permit ip 10.10.10.0 255.255.255.0 20.20.20.0 255.255.255.0
      local ident (addr/mask/prot/port): (10.10.10.0/255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (20.20.20.0/255.255.255.0/0/0)
      current_peer: 34.34.34.1

      #pkts encaps: 29, #pkts encrypt: 29, #pkts digest: 29
      #pkts decaps: 29, #pkts decrypt: 29, #pkts verify: 29
      ...

Note: When troubleshooting, if you do not see encapsulation (#pkts encaps) counters increasing on your end, the issue is likely local (e.g., routing, ACL). If you see encapsulation but no decapsulation (#pkts decaps), the issue is likely on the remote end.

You can use these debug commands on the ASA for further troubleshooting:

ASA1# debug crypto condition peer 34.34.34.1
ASA1# debug crypto ipsec
ASA1# debug crypto ikev1

To tear down the tunnel, you can use the following clear command:

ASA1# clear crypto isakmp sa
ASA1# Jan 24 12:11:32 [IKEv1]Group = 34.34.34.1, IP = 34.34.34.1, Session is being torn down. Reason: Administrator Reset

Frequently Asked Questions About Legacy VPN Security

Why is IKEv1 considered insecure?

IKEv1 is an older protocol that is less efficient and more complex than its successor, IKEv2. It lacks support for modern features like MOBIKE (mobility and multihoming) and is more susceptible to certain types of attacks. IKEv2 is the current industry standard for secure VPN key exchange.

What are the risks of using 3DES and MD5?

3DES (Triple DES) is a slow encryption algorithm vulnerable to attacks like “Sweet32,” which can allow an attacker to recover small amounts of plaintext. MD5 is a hashing algorithm that is considered “cryptographically broken,” meaning it’s possible to create hash collisions, compromising data integrity checks. Modern standards mandate the use of AES-256 for encryption and SHA-256 (or stronger) for hashing.

Why is DH Group 2 no longer safe?

Diffie-Hellman (DH) Group 2 uses a 1024-bit key, which is now considered too weak to resist attacks from well-resourced adversaries. It is vulnerable to pre-computation (like the Logjam attack), which could allow decryption of traffic. Secure networks should use DH groups 14 or higher, with groups 19, 20, or 21 being the recommended modern standard.

Conclusion

I hope this archival guide for configuring a legacy ASA 8.4 VPN was useful. For any new deployments, please refer to modern security standards and equipment.

6 Comments

  1. I’m not sure where you’re getting your info, but good topic. I needs to spend some time learning more or understanding more. Thanks for wonderful info I was looking for this information for my mission.

  2. This design is incredible! You obviously know how to keep
    a reader amused. Between your wit and your videos, I was almost moved to start my own
    blog (well, almost…HaHa!) Fantastic job. I really enjoyed what you had to say,
    and more than that, how you presented it.
    Too cool!

  3. It’s hard to find educated people in this particular subject, but you sound like you know what you’re talking about! Thanks

  4. I like what you guys tend to be up too. This type of clever work and coverage! Keep up the great works guys I’ve included you guys to my personal blogroll.

  5. We’re a group of volunteers and opening a new scheme in our community. Your site provided us with valuable info to work on. You’ve done a formidable job and our whole community will be thankful to you.

  6. Hi, Neat post. There is an issue along with your web site in internet explorer, could check this? IE still is the marketplace chief and a good component of other people will leave out your fantastic writing due to this problem.

Leave a Reply

Your email address will not be published. Required fields are marked *