Configure IKE
IKE, also called ISAKMP, is the negotiation protocol that lets two hosts agree on how to build an IPsec security association. To configure the ASA for Virtual Private Networks, you set global IKE parameters that apply system wide, and you also create IKE policies that the peers negotiate to establish a VPN connection.
Procedure
Step 1 | |
Step 2 | |
Step 3 |
Configure IKE Policies. |
Enable IKE
Procedure
Step 1 |
To enable IKE for VPN connections:
|
Step 2 |
To enable IKE for Site-to-Site VPN:
|
IKE Parameters for Site-to-Site VPN
In ASDM, choose Configuration > Site-to-Site VPN > Advanced > IKE Parameters.
NAT Transparency
-
Enable IPsec over NAT-T
IPsec over NAT-T lets IPsec peers establish both remote access and LAN-to-LAN connections through a NAT device. It does this by encapsulating IPsec traffic in UDP datagrams, using port 4500, thereby providing NAT devices with port information. NAT-T auto-detects any NAT devices, and only encapsulates IPsec traffic when necessary. This feature is enabled by default.
-
The ASA can simultaneously support standard IPsec, IPsec over TCP, NAT-T, and IPsec over UDP, depending on the client with which it is exchanging data.
-
When both NAT-T and IPsec over UDP are enabled, NAT-T takes precedence.
-
When enabled, IPsec over TCP takes precedence over all other connection methods.
The ASA implementation of NAT-T supports IPsec peers behind a single NAT/PAT device as follows:
-
One LAN-to-LAN connection.
-
Either a LAN-to-LAN connection or multiple remote access clients, but not a mixture of both.
To use NAT-T you must:
-
Create an ACL for the interface you will be using to open port 4500 (Configuration > Firewall > Access Rules).
-
Enable IPsec over NAT-T in this pane.
-
On the Fragmentation Policy parameter in the Configuration > Site-to-Site VPN > Advanced > IPsec Prefragmentation Policies pane, edit the interface you will be using to Enable IPsec pre-fragmentation. When this is configured, it is still alright to let traffic travel across NAT devices that do not support IP fragmentation; they do not impede the operation of NAT devices that do.
-
-
Enable IPsec over TCP
IPsec over TCP enables a VPN client to operate in an environment in which standard ESP or IKE cannot function, or can function only with modification to existing firewall rules. IPsec over TCP encapsulates both the IKE and IPsec protocols within a TCP packet, and enables secure tunneling through both NAT and PAT devices and firewalls. This feature is disabled by default.
Note
This feature does not work with proxy-based firewalls.
IPsec over TCP works with remote access clients. It works on all physical and VLAN interfaces. It is a client to ASA feature only. It does not work for LAN-to-LAN connections.
-
The ASA can simultaneously support standard IPsec, IPsec over TCP, NAT-Traversal, and IPsec over UDP, depending on the client with which it is exchanging data.
-
When enabled, IPsec over TCP takes precedence over all other connection methods.
You enable IPsec over TCP on both the ASA and the client to which it connects.
You can enable IPsec over TCP for up to 10 ports that you specify. If you enter a well-known port, for example port 80 (HTTP) or port 443 (HTTPS), the system displays a warning that the protocol associated with that port will no longer work. The consequence is that you can no longer use a browser to manage the ASA through the IKE-enabled interface. To solve this problem, reconfigure the HTTP/HTTPS management to different ports.
You must configure TCP port(s) on the client as well as on the ASA. The client configuration must include at least one of the ports you set for the ASA.
-
Identity Sent to Peer
Choose the Identity that the peers will use to identify themselves during IKE negotiations:
Address |
Uses the IP addresses of the hosts exchanging ISAKMP identity information. |
Hostname |
Uses the fully-qualified domain name of the hosts exchanging ISAKMP identity information (default). This name comprises the hostname and the domain name. |
Key ID |
Uses the remote peer uses the Key Id String that you specify to look up the preshared key. |
Automatic |
Determines IKE negotiation by connection type:
|
Session Control
-
Disable Inbound Aggressive Mode Connections
Phase 1 IKE negotiations can use either Main mode or Aggressive mode. Both provide the same services, but Aggressive mode requires only two exchanges between the peers, rather than three. Aggressive mode is faster, but does not provide identity protection for the communicating parties. It is therefore necessary that they exchange identification information prior to establishing a secure SA in which to encrypt in formation. This feature is disabled by default.
-
Alert Peers Before Disconnecting
-
Client or LAN-to-LAN sessions may be dropped for several reasons, such as: a ASA shutdown or reboot, session idle timeout, maximum connection time exceeded, or administrator cut-off.
-
The ASA can notify qualified peers (in LAN-to-LAN configurations) of sessions that are about to be disconnected, and it conveys to them the reason. The peer or client receiving the alert decodes the reason and displays it in the event log or in a pop-up pane. This feature is disabled by default.
-
This pane lets you enable the feature so that the ASA sends these alerts, and conveys the reason for the disconnect.
Qualified clients and peers include the following:
-
Security appliances with Alerts enabled.
-
VPN clients running 4.0 or later software (no configuration required).
-
-
Wait for All Active Sessions to Voluntarily Terminate Before Rebooting
You can schedule a ASA reboot to occur only when all active sessions have terminated voluntarily. This feature is disabled by default.
-
Number of SAs Allowed in Negotiation for IKEv1
Limits the maximum number of SAs that can be in negotiation at any time.
IKE v2 Specific Settings
Additional session controls are available for IKE v2, that limit the number of open SAs. By default, the ASA does not limit the number of open SAs:
-
Cookie Challenge—Enables the ASA to send cookie challenges to peer devices in response to SA initiate packets.
-
% threshold before incoming SAs are cookie challenged—The percentage of the total allowed SAs for the ASA that are in-negotiation, which triggers cookie challenges for any future SA negotiations. The range is zero to 100%. The default is 50%.
-
-
Number of Allowed SAs in Negotiation—Limits the maximum number of SAs that can be in negotiation at any time. If used in conjunction with Cookie Challenge, configure the cookie challenge threshold lower than this limit for an effective cross-check.
-
Maximum Number of SAs Allowed—Limits the number of allowed IKEv2 connections on the ASA. By default, the limit is the maximum number of connections specified by the license.
-
Notify Invalid Selector—Allows an administrator to enable or disable the sending of an IKE notification to the peer when an inbound packet that is received on an SA does not match the traffic selectors for that SA. Sending this notification is disabled by default.
Preventing DoS Attacks with IKE v2 Specific Settings
You can prevent denial-of-service (DoS) attacks for IPsec IKEv2 connections by configuring Cookie Challenge, which challenges the identify of incoming Security Associations (SAs), or by limiting the number of open SAs. By default, the ASA does not limit the number of open SAs, and never cookie challenges SAs. You can also limit the number of SAs allowed, which stops further connections from negotiating to protect against memory and/or CPU attacks that the cookie-challenge feature may be unable to thwart and protects the current connections.
With a DoS attack, an attacker initiates the attack when the peer device sends an SA initiate packet and the ASA sends its response, but the peer device does not respond further. If the peer device does this continually, all the allowed SA requests on the ASA can be used up until it stops responding.
Enabling a threshold percentage for cookie challenging limits the number of open SA negotiations. For example, with the default setting of 50%, when 50% of the allowed SAs are in-negotiation (open), the ASA cookie challenges any additional SA initiate packets that arrive. For the Cisco ASA 5585-X with 10000 allowed IKEv2 SAs, after 5000 SAs become open, any more incoming SAs are cookie-challenged.
If used in conjunction with the Number of SAs Allowed in Negotiation , or the Maximum Number of SAs Allowed, configure the cookie-challenge threshold lower than these settings for an effective cross-check.
You can also limit the life on all SAs at the IPsec level by choosing Configuration > Site-to-Site VPN > Advanced > System Options.
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.
![](/c/dam/en/us/td/i/400001-500000/440001-450000/440001-441000/440304.jpg)
![]() 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.
IKE Policies
Configuration > Site-to-Site VPN > Advanced > IKE Policies
Use this pane to Add, Edit, or Delete IKEv1 and IKEv2 Policies.
To set the terms of the IKE negotiations, you create one or more IKE policies, which include the following:
-
A unique priority (1 through 65,543, with 1 the highest priority).
-
An authentication method, to ensure the identity of the peers.
-
An encryption method, to protect the data and ensure privacy.
-
An 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 establish the strength of the of the encryption-key-determination algorithm. The ASA uses this algorithm to derive the encryption and hash keys.
-
A limit for how long the ASA uses an encryption key before replacing it.
Each IKE negotiation is divided into two sections called Phase1 and Phase 2. Phase 1 creates the first tunnel, which protects later IKE negotiation messages. Phase 2 creates the tunnel that protects data.
For IKEv1, you can only enable one setting for each parameter. For IKEv2, each proposal can have multiples settings for Encryption, D-H Group, Integrity Hash, and PRF Hash.
If you do not configure any IKE policies, the ASA uses the default policy, which is always set to the lowest priority, and which contains the default value for each parameter. If you do not specify a value for a specific parameter, the default value takes effect.
When IKE negotiation begins, the peer that initiates the negotiation sends all of its policies to the remote peer, and the remote peer searches for a match with its own policies, in priority order.
A match between IKE policies exists if they have the same encryption, hash, authentication, and Diffie-Hellman values, and an SA lifetime less than or equal to the lifetime in the policy sent. If the lifetimes are not identical, the shorter lifetime—from the remote peer policy—applies. If no match exists, IKE refuses negotiation and the IKE SA is not established.
Fields
-
IKEv1 Policies—Displays parameter settings for each configured IKE policy.
-
Priority #—Shows the priority of the policy.
-
Encryption—Shows the encryption method.
-
Hash—Shows the hash algorithm.
-
D-H Group—Shows the Diffie-Hellman group.
-
Authentication—Shows the authentication method.
-
Lifetime (secs)—Shows the SA lifetime in seconds.
-
-
IKEv2 Policies—Displays parameter settings for each configured IKEv2 policy.
-
Priority #—Shows the priority of the policy.
-
Encryption—Shows the encryption method.
-
Integrity Hash—Shows the hash algorithm.
-
PRF Hash—Shows the pseudo random function (PRF) hash algorithm.
-
D-H Group—Shows the Diffie-Hellman group.
-
Lifetime (secs)—Shows the SA lifetime in seconds.
-
Add or Edit an IKEv1 Policy
Configuration > Site-to-Site VPN > Advanced > IKE Policies > Add/Edit IKE Policy
Priority #—Type a number to set a priority for the IKE policy. The range is 1 to 65535, with 1 the highest priority.
Encryption—Choose an encryption method. This is a symmetric encryption method that protects data transmitted between two IPsec peers.The choices follow:
des |
56-bit DES-CBC. Less secure but faster than the alternatives. The default. |
3des |
168-bit Triple DES. |
aes |
128-bit AES. |
aes-192 |
192-bit AES. |
aes-256 |
256-bit AES. |
Hash—Choose the hash algorithm that ensures data integrity. It ensures that a packet comes from whom you think it comes from, and that it has not been modified in transit.
sha |
SHA-1 |
The default is SHA-1. MD5 has a smaller digest and is considered to be slightly faster than SHA-1. A successful (but extremely difficult) attack against MD5 has occurred; however, the HMAC variant IKE uses prevents this attack. |
md5 |
MD5 |
Authentication—Choose the authentication method the ASA uses to establish the identity of each IPsec peer. Preshared keys do not scale well with a growing network, but are easier to set up in a small network. The choices follow:
pre-share |
Preshared keys. |
rsa-sig |
A digital certificate with keys generated by the RSA signatures algorithm. |
D-H Group—Choose the Diffie-Hellman group identifier, which the two IPsec peers use to derive a shared secret without transmitting it to each other.
1 |
Group 1 (768-bit) |
Group 2 (1024-bit Diffie-Hellman) requires less CPU time to execute but is less secure than Group 1or 5. |
2 |
Group 2 (1024-bit) |
|
5 |
Group 5 (1536-bit) |
|
14 |
Group 14 (2048-bit) |
The default Diffie-Hellman group is, Group 14 (2048-bit Diffie-Hellman) |
Lifetime (secs)—Either check Unlimited or enter an integer for the SA lifetime. The default is 86,400 seconds or 24 hours. With longer lifetimes, the ASA sets up future IPsec security associations less quickly. Encryption strength is great enough to ensure security without using very fast rekey times, on the order of every few minutes. We recommend that you accept the default.
Time Measure—Choose a time measure. The ASA accepts the following values:.
120 - 86,400 seconds |
2 - 1440 minutes |
1 - 24 hours |
1 day |
Add or Edit an IKEv2 Policy
Configuration > Site-to-Site VPN > Advanced > IKE Policies > Add/Edit IKEv2 Policy
Priority #—Type a number to set a priority for the IKEv2 policy. The range is 1 to 65535, with 1 the highest priority.
Encryption—Choose an encryption method. This is a symmetric encryption method that protects data transmitted between two IPsec peers.The choices follow:
des |
Specifies 56-bit DES-CBC encryption for ESP. |
3des |
(Default) Specifies the triple DES encryption algorithm for ESP. |
aes |
Specifies AES with a 128-bit key encryption for ESP. |
aes-192 |
Specifies AES with a 192-bit key encryption for ESP. |
aes-256 |
Specifies AES with a 256-bit key encryption for ESP. |
aes-gcm |
Specifies AES-GCM/GMAC 128-bit support for symmetric encryption and integrity. |
aes-gcm-192 |
Specifies AES-GCM/GMAC 192-bit support for symmetric encryption and integrity. |
aes-gcm-256 |
Specifies AES-GCM/GMAC 256-bit support for symmetric encryption and integrity. |
NULL |
Indicates no encryption. |
D-H Group—Choose the Diffie-Hellman group identifier, which the two IPsec peers use to derive a shared secret without transmitting it to each other.
1 |
Group 1 (768-bit) |
The default, Group 2 (1024-bit Diffie-Hellman) requires less CPU time to execute but is less secure than Group 2 or 5. |
2 |
Group 2 (1024-bit) |
|
5 |
Group 5 (1536-bit) |
|
14 |
Group 14 |
|
19 |
Group 19 |
|
20 |
Group 20 |
|
21 |
Group 21 |
|
24 |
Group 24 |
Integrity Hash—Choose the hash algorithm that ensures data integrity for the ESP protocol. It ensures that a packet comes from whom you think it comes from, and that it has not been modified in transit.
sha |
SHA 1 |
The default is SHA 1. MD5 has a smaller digest and is considered to be slightly faster than SHA 1. A successful (but extremely difficult) attack against MD5 has occurred; however, the HMAC variant IKE uses prevents this attack. |
md5 |
MD5 |
|
sha256 |
SHA 2, 256-bit digest |
Specifies the Secure Hash Algorithm SHA 2 with the 256-bit digest. |
sha384 |
SHA 2, 384-bit digest |
Specifies the Secure Hash Algorithm SHA 2 with the 384-bit digest. |
sha512 |
SHA 2, 512-bit digest |
Specifies the Secure Hash Algorithm SHA 2 with the 512-bit digest. |
null |
Indicates that AES-GCM or AES-GMAC is configured as the encryption algorithm. You must choose the null integrity algorithm if AES-GCM has been configured as the encryption algorithm. |
Pseudo-Random Function (PRF)—Specify the PRF used for the construction of keying material for all of the cryptographic algorithms used in the SA..
sha |
SHA-1 |
The default is SHA-1. MD5 has a smaller digest and is considered to be slightly faster than SHA-1. A successful (but extremely difficult) attack against MD5 has occurred; however, the HMAC variant IKE uses prevents this attack. |
md5 |
MD5 |
|
sha256 |
SHA 2, 256-bit digest |
Specifies the Secure Hash Algorithm SHA 2 with the 256-bit digest. |
sha384 |
SHA 2, 384-bit digest |
Specifies the Secure Hash Algorithm SHA 2 with the 384-bit digest. |
sha512 |
SHA 2, 512-bit digest |
Specifies the Secure Hash Algorithm SHA 2 with the 512-bit digest. |
Lifetime (secs)—Either check Unlimited or enter an integer for the SA lifetime. The default is 86,400 seconds or 24 hours. With longer lifetimes, the ASA sets up future IPsec security associations more quickly. Encryption strength is great enough to ensure security without using very fast rekey times, on the order of every few minutes. We recommend that you accept the default.
The ASA accepts the following values:.
120 - 86,400 seconds |
2 - 1440 minutes |
1 - 24 hours |
1 day |