Cisco Bug: CSCtb16115 - IKEv1-IPSec NAT behavioral changes
Feb 02, 2017
- Cisco IOS
Known Affected Releases
Symptom: Few of the NAT scenarios get broken for IKEv2 and IKEv1. Conditions: 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. Solution:<B:> 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 Cisco.com account to be viewed.
Bug Details Include
- Full Description (including symptoms, conditions and workarounds)
- Known Fixed Releases
- Related Community Discussions
- Number of Related Support Cases