Project

General

Profile

Actions
Copy link

Bug #4208

closed

P1 rekeying with IKEv1 failing with no proposal chosen / invalid ID info

Added by Chris Buechler over 9 years ago. Updated almost 9 years ago.

Status:
Resolved
Priority:
Very High
Assignee:
Ermal Luçi
Category:
IPsec
Target version:
-
Start date:
01/12/2015
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.2
Affected Architecture:

Description

When P1 rekeys with IKEv1, in certain circumstances (which aren't entirely clear) it'll end up failing with no proposal chosen. One example here with logs:
https://forum.pfsense.org/index.php?topic=86621.0

The same thing happened to one of my VPNs today where it was 2.2 on both ends, so it also applies to strongswan to strongswan connections.

Along the same lines, but a slightly different symptom, it may also do the following: 

Jan 12 21:14:05    charon: 14[KNL] creating rekey job for ESP CHILD_SA with SPI cc825a3b and reqid {4}
Jan 12 21:14:05    charon: 16[ENC] generating QUICK_MODE request 3257512338 [ HASH SA No KE ID ID 
Jan 12 21:14:05    charon: 16[ENC] parsed INFORMATIONAL_V1 request 1371235738 [ HASH N(INVAL_ID) ]
Jan 12 21:14:05    charon: 16[IKE] <con3000|410> received INVALID_ID_INFORMATION error notify
Jan 12 21:14:05    charon: 16[IKE] received INVALID_ID_INFORMATION error notify

Where both sides end up with more or less the same logs.

I shortened the P1 lifetime on some of our test VPNs, and a couple of my home production ones, to see if it's reliably replicable. Thus far it seems a bit hit and miss. It doesn't appear to affect IKEv2 at all.

Actions
Copy link
 #1

Updated by Chris Buechler over 9 years ago

  • Assignee set to Chris Buechler

to me for further info

Actions
Copy link
 #2

Updated by Chris Buechler over 9 years ago

adding some details from what I've found thus far.

  • It's not universal, but it is replicable. It's not replicable on demand, though, from what I've found thus far.
  • Reducing the lifetime significantly seems to either eliminate, or delay the issue well beyond the first rekey at least. Seems the scenario for kitdavis in the linked forum post is it happens on the first P1 rekey. Testing with a 1200 P1 lifetime and 600 P2, I have several tunnels that have rekeyed a number of times without exhibiting the issue.
  • This started at some point last week, judging from log history exhibiting the issue. I haven't been able to narrow down the specific day.
  • It doesn't seem to be specific to any particular config parameters. There are reports of it affecting main and aggressive modes, various ciphers, hash, lifetime, etc. None of the affected ones I've seen or heard of are using NAT-T, but that's probably more a function of most site to site VPNs not using NAT-T. None of the systems that have exhibited the issue have any NAT-T VPNs on them.
Actions
Copy link
 #3

Updated by Chris Buechler over 9 years ago

  • Assignee changed from Chris Buechler to Ermal Luçi

I haven't found a means of reliably replicating this with shorter lifetimes. It's either some combination of things that I haven't been able to replicate, or specific to longer lifetimes. Hoping we can get access to kitdavis' system shortly since it's seemingly more reliably replicable there, I reached out to him.

Ermal and I discussed, he's looking into changes last week to see if anything sticks out, in our code and strongswan 5.2.1->5.2.2.

Actions
Copy link
 #4

Updated by Ermal Luçi over 9 years ago

Actions
Copy link
 #5

Updated by Ermal Luçi over 9 years ago

The first one hsa been reverted and is present on new snaps.

Actions
Copy link
 #6

Updated by Chris Buechler over 9 years ago

strongswan has been reverted back to 5.2.1 to see if that resolves the issue, as other possibilities seem to have been exhausted.

Actions
Copy link
 #7

Updated by Chris Buechler over 9 years ago

  • Status changed from Confirmed to Feedback

downgrade to strongswan 5.2.1 (with cherry-picked security fixes from 5.2.2) looks to have fixed this issue. Leaving to feedback for now

Actions
Copy link
 #8

Updated by Chris Buechler over 9 years ago

  • Target version changed from 2.2 to 2.2.1

that did fix the issue for 2.2, pushing to 2.2.1 for getting the issue fixed in strongswan 5.2.2.

Actions
Copy link
 #9

Updated by Chris Buechler about 9 years ago

  • Target version changed from 2.2.1 to 2.2.2
Actions
Copy link
 #10

Updated by Chris Buechler about 9 years ago

  • Target version changed from 2.2.2 to 2.2.3
Actions
Copy link
 #11

Updated by Chris Buechler almost 9 years ago

  • Status changed from Feedback to Resolved
  • Target version deleted (2.2.3)

this was fixed in strongswan 5.3.0

Actions
Copy link

Also available in: Atom PDF