About Tunneling, IPsec, and ISAKMP
This topic describes the Internet Protocol Security (IPsec) and the Internet Security Association and Key Management Protocol (ISAKMP) standards used to build Virtual Private Networks (VPNs).
Tunneling makes it possible to use a public TCP/IP network, such as the Internet, to create secure connections between remote users and a private corporate network. Each secure connection is called a tunnel.
The ASA uses the ISAKMP and IPsec tunneling standards to build and manage tunnels. ISAKMP and IPsec accomplish the following:
-
Negotiate tunnel parameters
-
Establish tunnels
-
Authenticate users and data
-
Manage security keys
-
Encrypt and decrypt data
-
Manage data transfer across the tunnel
-
Manage data transfer inbound and outbound as a tunnel endpoint or router
The ASA functions as a bidirectional tunnel endpoint. It can receive plain packets from the private network, encapsulate them, create a tunnel, and send them to the other end of the tunnel where they are unencapsulated and sent to their final destination. It can also receive encapsulated packets from the public network, unencapsulate them, and send them to their final destination on the private network.
IPsec Overview
The ASA uses IPsec for LAN-to-LAN VPN connections and provides the option of using IPsec for client-to-LAN VPN connections. In IPsec terminology, a peer is a remote-access client or another secure gateway. For both connection types, the ASA supports only Cisco peers. Because we adhere to VPN industry standards, ASAs can work with other vendors' peers; however, we do not support them.
During tunnel establishment, the two peers negotiate security associations that govern authentication, encryption, encapsulation, and key management. These negotiations involve two phases: first, to establish the tunnel (the IKE SA) and second, to govern traffic within the tunnel (the IPsec SA).
A LAN-to-LAN VPN connects networks in different geographic locations. In IPsec LAN-to-LAN connections, the ASA can function as initiator or responder. In IPsec client-to-LAN connections, the ASA functions only as responder. Initiators propose SAs; responders accept, reject, or make counter-proposals—all in accordance with configured SA parameters. To establish a connection, both entities must agree on the SAs.
Understanding IPsec Tunnels
IPsec tunnels are sets of SAs that the ASA establishes between peers. The SAs specify the protocols and algorithms to apply to sensitive data and also specify the keying material that the peers use. IPsec SAs control the actual transmission of user traffic. SAs are unidirectional, but are generally established in pairs (inbound and outbound).
The peers negotiate the settings to use for each SA. Each SA consists of the following:
-
IKEv1 transform sets or IKEv2 proposals
-
Crypto maps
-
ACLs
-
Tunnel groups
-
Prefragmentation policies
ISAKMP and IKE Overview
ISAKMP is the negotiation protocol that lets two hosts agree on how to build an IPsec security association (SA). It provides a common framework for agreeing on the format of SA attributes. This security association includes negotiating with the peer about the SA and modifying or deleting the SA. ISAKMP separates negotiation into two phases: Phase 1 and Phase 2. Phase 1 creates the first tunnel, which protects later ISAKMP negotiation messages. Phase 2 creates the tunnel that protects data.
IKE uses ISAKMP to set up the SA for IPsec to use. IKE creates the cryptographic keys used to authenticate peers.
The ASA supports IKEv1 for connections from the legacy Cisco VPN client, and IKEv2 for the AnyConnect VPN client.
To set the terms of the ISAKMP negotiations, you create an IKE policy, which includes the following:
-
The authentication type required of the IKEv1 peer, either RSA signature using certificates or preshared key (PSK).
-
An encryption method to protect the data and ensure privacy.
-
A Hashed Message Authentication Codes (HMAC) method to ensure the identity of the sender, and to ensure that the message has not been modified in transit.
-
A Diffie-Hellman group to determine the strength of the encryption-key-determination algorithm. The ASA uses this algorithm to derive the encryption and hash keys.
-
For IKEv2, a separate pseudo-random function (PRF) used as the algorithm to derive keying material and hashing operations required for the IKEv2 tunnel encryption and so on.
-
A limit to the time the ASA uses an encryption key before replacing it.
With IKEv1 policies, you set one value for each parameter. For IKEv2, you can configure multiple encryption and authentication types, and multiple integrity algorithms for a single policy. The ASA orders the settings from the most secure to the least secure and negotiates with the peer using that order. This ordering allows you to potentially send a single proposal to convey all the allowed transforms instead of sending each allowed combination as with IKEv1.
The ASA does not support IKEv2 multiple security associations (SAs). The ASA currently accepts inbound IPsec traffic only
on the first SA that is found. If IPsec traffic is received on any other SA, it is dropped with reason vpn-overlap-conflict
. Multiple IPsec SAs can come about from duplicate tunnels between two peers, or from asymmetric tunneling.
Understanding IKEv1 Transform Sets and IKEv2 Proposals
An IKEv1 transform set or an IKEv2 proposal is a combination of security protocols and algorithms that define how the ASA protects data. During IPsec SA negotiations, the peers must identify a transform set or proposal that is the same at both peers. The ASA then applies the matching transform set or proposal to create an SA that protects data flows in the ACL for that crypto map.
With IKEv1 transform sets, you set one value for each parameter. For IKEv2 proposals, you can configure multiple encryption and authentication types and multiple integrity algorithms for a single proposal. The ASA orders the settings from the most secure to the least secure and negotiates with the peer using that order. This allows you to potentially send a single proposal to convey all the allowed combinations instead of the need to send each allowed combination individually as with IKEv1.
The ASA tears down the tunnel if you change the definition of the transform set or proposal used to create its SA. See the Clear Security Associations” for further information.
Note |
If you clear or delete the only element in a transform set or proposal, the ASA automatically removes the crypto map references to it. |