Preview Tool

Cisco Bug: CSCtb16115 - IKEv1-IPSec NAT behavioral changes

Last Modified

Feb 02, 2017

Products (1)

  • Cisco IOS

Known Affected Releases


Description (partial)

Few of the NAT scenarios get broken for IKEv2 and IKEv1. 

Few scenarios:
1) In IKEv2 scenario, when both the initiator and responder are behind NAT and 2 IPSec SAs are brought up for 2 ACLs under same IKE SA and then when the entire session is cleared, a new connection initiation for the first ACL does not bring up the IKE SA. This happens since the request goes out with port 4500 which is wrong.

2) In a IKEv1 scenario with a NAT in between, consider a scenario where the IKE SA  is deleted and the IPSec SA remains. When the IPSec SA re-keys, it would send ports  4500,4500 to IKE. IKE would then start a new negotiation with (4500,4500) which is wrong.

Changes have been made in IPSec and IKEv1 so that all scenarios got addressed:
1. IPSec will always send on ports 500,500 for a fresh SA requests and ports from the IPSec SA in case of IPSec re-key.
2. IKEv1 will initiate IKE session with ports 500,500 so that scenario No.2 will get addressed
3. As a result of the changes, ports 500 will always be sent on a fresh SA request. Hence, when a device initiates a new connection, IKE searches in the database to determine if an IKE SA already exists or not. If there is an existing IKE SA, we will use this IKE SA to create the IPSec SAs instead of creating a new IKE SA pair.
Bug details contain sensitive information and therefore require a account to be viewed.

Bug Details Include

  • Full Description (including symptoms, conditions and workarounds)
  • Status
  • Severity
  • Known Fixed Releases
  • Related Community Discussions
  • Number of Related Support Cases
Bug information is viewable for customers and partners who have a service contract. Registered users can view up to 200 bugs per month without a service contract.