This document provides information on how to configure a VPN gateway device to always act as a responder in an IKE negotiation. The device will respond to any crypto negotiations initiated by its peers.
There are no specific requirements for this document.
The information in this document is based on these software and hardware versions:
This document can also be used with these hardware and software versions:
Refer to Cisco Technical Tips Conventions for more information on document conventions.
Any crypto negotiation has two parties to play the Initiator and Responder roles. The initiator sends the crypto proposals to the responder which contains different parameters about the encryption, authentication algorithms, re-keying options and the life-time values and so forth. The responder chooses the right proposal and a crypto session establishes. The role played by an end-device can be viewed by this command output:
Router#show crypto isakmp sa
1 IKE Peer: XX.XX.XX.XX
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
ASA(config)#show crypto isakmp sa detail
IKE Peer Type Dir Rky State Encrypt Hash Auth Lifetime
1 220.127.116.11 User Resp No AM_Active 3des SHA preshrd 86400
Since the advent of virtual private network (VPN) features that allow simultaneous bidirectional IKE negotiations (with or without interesting traffic), issues with the handling and recovery of data from duplicate IKE SAs have occurred. IKE as a protocol has no ability to compare IKE negotiations to determine whether there is already an existing or in-process negotiation between two peers taking place. These duplicate negotiations can be costly in terms of resources and confusing to router administrators. When a device is configured as a responder-only device, it will not initiate IKE main, aggressive, or quick modes (for IKE and IPSec SA establishment), nor will it rekey IKE and IPSec SAs. Therefore, the likelihood of duplicate SAs is reduced.
The other benefit of this feature is to allow controlled support for negotiating connections in one direction only in a load-balancing scenario. It is not recommended that the servers or hubs initiate VPN connections toward the clients or spokes because these devices are all being accessed by a single-facing IP address as advertised via the load balancer. If the hubs were to initiate the connection, they would be doing so using an individual IP address, thus circumventing the benefits of the load balancer. The same is true of rekeying requests that are sourced from the hubs or servers behind the load balancer.
Cisco IOS Software Release 12.4(24)T introduces the functionality of the router to always respond to the IKE negotiations initiated by its peers. The main limitation is that this feature is configurable only under an IPSec profile and is relevant only to a virtual interface scenario. No support for static or dynamic crypto map scenarios.
In order to configure your router as responder-only, perform these steps:
crypto ipsec profile <name>
In general 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. An ASA can be configured as respond-only device in LAN-to-LAN VPN connections. However, the restriction is that the device at the other end of the VPN tunnel must be one of these:
Cisco ASA 5500 series appliance
Cisco VPN 3000 series Concentrator
Cisco PIX 500 series firewall that runs 7.0 software and later
In order to configure your ASA as responder-only device, issue this command:
hostname(config)# crypto map mymap 10 set connection-type answer-only
Note: It is suggested to configure a VPN gateway device as responder-only where multiple VPN peers terminate.