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 (SAs) 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. |
About IKEv2 Multi-Peer Crypto Map
Beginning with the 9.14(1) release, ASA IKEv2 supports multi-peer crypto map—when a peer in a tunnel goes down, IKEv2 attempts to establish the tunnel with the next peer in the list. You can configure crypto map with a maximum of 10 peer addresses. This multiple peer support on IKEv2 is useful, especially, when you are migrating from IKEv1 with multi-peer crypto maps.
IKEv2 supports only bi-directional crypto maps. Hence, the multiple peers are also configured on bi-directional crypto maps, and the same is used to accept the request from peers initiating the tunnel.
IKEv2 Initiator Behavior
IKEv2 initiates session with a peer, say Peer1. If Peer1 is unreachable for 5 SA_INIT retransmits, a final retransmit is sent. This activity takes about 2 minutes.
When Peer1 fails, the SA_INIT message is sent to Peer2. If Peer2 is also unreachable, session establishment is initiated with Peer3 after 2 minutes.
After all the peers are exhausted in the peer list of the crypto map, IKEv2 initiates the session again from Peer1 until a SA is established with any of the peers. The following figure depicts this behavior.
Note |
Continuous traffic is required to initiate IKE SA so that each failure attempt would move to the next peer and finally some reachable peer establishes the SA. In cases of disrupted traffic, a manual trigger is needed to initiate the IKE SA with the next peer. |
IKEv2 Responder Behavior
If the responder device of IKE SA is configured with multiple peers in the crypto map, whenever an IKE SA is attempted, the address of the initiator IKE SA is validated with that of the current active peer in the crypto map.
For example, if the current active peer in the crypto map (being used as Responder) is the first peer, then the IKE SA is initiated from Peer1 IP address. Similarly, if the current active peer in the crypto map (being used as Responder) is the second peer, then IKE SA is initiated from Peer2 IP address.
Note |
Peer traversal is not supported on the Responder Side of a IKEv2 multi-peer topology. |
Peer Index Reset Upon Crypto Map Changes
Any change to the crypto map resets the peer index to zero, and the tunnel initiation starts from first peer in the list. Following table provides multiple peer index transition under specific conditions:
Conditions prior to SA |
Peer Index Moved Yes/No/Reset |
---|---|
Peer not reachable |
Yes |
Phase 1 proposal mismatch |
Yes |
Phase 2 proposal mismatch |
Yes |
DPD ack not received |
Yes |
Traffic selectors mismatch during AUTH phase |
Yes |
Authentication failure |
Yes |
Rekey failure due to peer not reachable |
Reset |
Conditions after SA |
Peer Index Moved Yes/No/Reset |
---|---|
Rekey failure due to proposal mismatch |
Reset |
Traffic selectors mismatch during rekey |
Reset |
Crypto map modification |
Reset |
HA switchover |
No |
Clear crypto IKEv2 SA |
Reset |
Clear ipsec sa |
Reset |
IKEv2 SA timeout |
Reset |
Guidelines for IKEv2 Multi-Peer
IKEv1 and IKEv2 Protocols
If a crypto map is configured with both the IKE versions and multiple peers, SA attempt is made on each peer with both versions before moving to next peer.
For example, if a crypto map is configured with two peers, say P1 and P2, then the tunnel is initiated to P1 with IKEv2, P1 with IKEv1, P2 with IKEv2, and so on.
High Availability
A crypto map with multiple peers initiates tunnels to the Responder device that is in HA. It moves to the next Responder device when the first device isn’t reachable.
An initiator device initiates tunnels to the Responder device. If the active device goes down, the standby device attempts to establish the tunnel from the Peer1 IP address, irrespective of the crypto map moving to the Peer2 IP address on the active device.
Centralized Cluster
A crypto map with multiple peers can initiate tunnels to the Responder device that is in a Centralized cluster deployment. If the first device is unreachable, it attempts to move to the next Responder device.
An initiator device initiates tunnels to the Responder device. Every node in the cluster moves to the next Peer2, if Peer1 isn’t reachable.
Distributed Cluster
Distributed clustering isn’t supported when an IKEv2 multi-peer crypto map is configured.
Multiple Context Modes
In multiple context modes, multi-peer behavior is specific to each context.
Debug Command
If the tunnel establishment fails, enable these commands to further analyse the issue.
-
debug crypto ikev2 platform 255
-
debug crypto ikev2 protocol 255
-
debug crypto ike-common 255
Sep 13 10:08:58 [IKE COMMON DEBUG]Failed to initiate ikev2 SA with peer 192.168.2.2,
initiate to next peer 192.168.2.3 configured in the multiple peer list of the crypto map.