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, thus 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 being sourced from the hubs or servers behind the load balancer.
This feature is particularly relevant in static virtual interfaces where events such as routing protocol convergence can generate
simultaneous tunnel negotiations.
Feedback