Actions
Bug #4208
closed
P1 rekeying with IKEv1 failing with no proposal chosen / invalid ID info
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.
Updated by 
Updated by Ermal Luçi
Actions