Bug #4266
closed
Rekeying issues with IKEv1 and multiple P2s under some circumstances
0%
Description
Where you have multiple P2s configured on a single P1 with IKEv1, there are some rekeying issues under some circumstances that haven't been fully quantified yet.
Example logs you end up with from strongswan:
Jan 19 15:43:16 pf charon: 02[ENC] generating INFORMATIONAL_V1 request 3956259368 [ HASH N(DPD) ]
Jan 19 15:43:16 pf charon: 02[NET] sending packet: from ip1[500] to ip2[500] (92 bytes)
Jan 19 15:43:16 pf charon: 02[NET] received packet: from ip2[500] to ip1[500] (92 bytes)
Jan 19 15:43:16 pf charon: 02[ENC] parsed INFORMATIONAL_V1 request 735452451 [ HASH N(DPD_ACK) ]
Jan 19 15:43:20 pf charon: 02[NET] received packet: from ip3[500] to ip1[500] (364 bytes)
Jan 19 15:43:20 pf charon: 02[ENC] parsed QUICK_MODE request 141741184 [ HASH SA No KE ID ID ]
Jan 19 15:43:20 pf charon: 02[ENC] received HASH payload does not match
Jan 19 15:43:20 pf charon: 02[IKE] <con2000|13> integrity check failed
Jan 19 15:43:20 pf charon: 02[IKE] integrity check failed
Jan 19 15:43:20 pf charon: 02[ENC] generating INFORMATIONAL_V1 request 1348227468 [ HASH N(INVAL_HASH) ]
Jan 19 15:43:20 pf charon: 02[NET] sending packet: from ip1[500] to ip3[500] (76 bytes)
Jan 19 15:43:20 pf charon: 02[IKE] <con2000|13> QUICK_MODE request with message ID 141741184 processing failed
Jan 19 15:43:20 pf charon: 02[IKE] QUICK_MODE request with message ID 141741184 processing failed
Jan 19 15:43:21 pf charon: 02[IKE] <con2000|13> sending DPD request
Jan 19 15:43:21 pf charon: 02[IKE] sending DPD request
Jan 19 15:43:21 pf charon: 02[ENC] generating INFORMATIONAL_V1 request 3461990251 [ HASH N(DPD) ]
Jan 19 15:43:21 pf charon: 02[NET] sending packet: from ip1[500] to ip3[500] (92 bytes)
Jan 19 15:43:21 pf charon: 02[NET] received packet: from ip3[500] to ip1[500] (92 bytes)
Jan 19 15:43:21 pf charon: 02[ENC] parsed INFORMATIONAL_V1 request 3939011389 [ HASH N(DPD_ACK) ]
Jan 19 15:43:21 pf charon: 02[NET] received packet: from ip3[500] to ip1[500] (364 bytes)
Jan 19 15:43:21 pf charon: 02[ENC] parsed QUICK_MODE request 3030064237 [ HASH SA No KE ID ID ]
Jan 19 15:43:21 pf charon: 02[IKE] <con2000|13> detected rekeying of CHILD_SA con2000{4}
Jan 19 15:43:21 pf charon: 02[IKE] detected rekeying of CHILD_SA con2000{4}
Jan 19 15:43:21 pf charon: 02[ENC] generating QUICK_MODE response 3030064237 [ HASH SA No KE ID ID ]
Jan 19 15:43:21 pf charon: 02[NET] sending packet: from ip1[500] to ip3[500] (380 bytes)
Jan 19 15:43:21 pf charon: 02[NET] received packet: from ip3[500] to ip1[500] (76 bytes)
Jan 19 15:43:21 pf charon: 02[ENC] parsed INFORMATIONAL_V1 request 2447641578 [ HASH N(INVAL_ID) ]
Jan 19 15:43:21 pf charon: 02[IKE] <con2000|13> received INVALID_ID_INFORMATION error notify
Jan 19 15:43:21 pf charon: 02[IKE] received INVALID_ID_INFORMATION error notify
Jan 19 15:43:21 pf charon: 02[IKE] <con2000|13> received INVALID_ID_INFORMATION error notify
Jan 19 15:43:21 pf charon: 02[IKE] received INVALID_ID_INFORMATION error notify
Jan 19 15:43:26 pf charon: 16[NET] received packet: from ip3[500] to ip1[500] (364 bytes)
Jan 19 15:43:26 pf charon: 16[ENC] parsed QUICK_MODE request 84872551 [ HASH SA No KE ID ID ]
Jan 19 15:43:26 pf charon: 16[IKE] <con2000|13> detected rekeying of CHILD_SA con2000{4}
Jan 19 15:43:26 pf charon: 16[IKE] detected rekeying of CHILD_SA con2000{4}
Jan 19 15:43:26 pf charon: 16[ENC] generating QUICK_MODE response 84872551 [ HASH SA No KE ID ID ]
Jan 19 15:43:26 pf charon: 16[NET] sending packet: from ip1[500] to ip3[500] (380 bytes)
Jan 19 15:43:26 pf charon: 16[NET] received packet: from ip3[500] to ip1[500] (76 bytes)
Jan 19 15:43:26 pf charon: 16[ENC] parsed INFORMATIONAL_V1 request 4148709878 [ HASH N(INVAL_ID) ]
Jan 19 15:43:26 pf charon: 16[IKE] <con2000|13> received INVALID_ID_INFORMATION error notify
Jan 19 15:43:26 pf charon: 16[IKE] received INVALID_ID_INFORMATION error notify
Jan 19 15:43:26 pf charon: 16[IKE] <con2000|13> received INVALID_ID_INFORMATION error notify
Files
Updated by Chris Buechler almost 10 years ago
- Assignee set to Chris Buechler
to me for info gathering
Updated by Ermal Luçi over 9 years ago
More testing should be done related to rekey, uniqueids and DPD closeaction statement which might impact this.
Updated by Ermal Luçi over 9 years ago
Also looking at this thread http://comments.gmane.org/gmane.network.vpn.strongswan.user/2055
It can be a solution to be tested on the matter.
Updated by Ermal Luçi over 9 years ago
Also this issue on redmine https://wiki.strongswan.org/issues/431 recommends reauth = no for IKEv2 for IKEv1 not sure what can be the solution apart disabling rekey.
Updated by Ermal Luçi over 9 years ago
Some people have reported that this happens only if prefer oldsa setting is enabled.
Updated by tb o over 9 years ago
We have several systems with that issue, none of them has "prefer older ipsec sa" enabled (switching that option does not make a difference).
But we have one device which had the snapshot RC installed. After upgrading to final 2.2 the issue with rekeying occurs.
After downgrading everything is again fine.
The working version is:
2.2-RC (amd64)
built on Fri Jan 16 11:53:08 CST 2015
Updated by Chris Buechler over 9 years ago
Thanks for that, Christian. I believe this issue pre-dates that timing, though I see one specific change in that timeframe which could impact things in some circumstances.
Do you have a system live exhibiting the problem where you can try something? Install the System Patches package, then go to System>Patches and click +. Give it a description, and paste in this URL: https://files.pfsense.org/cmb/strongswan-omit-interfaces_use.diff
Leave all else at defaults, click Save. Then click Fetch, then Test. It should show applies cleanly, won't revert. Then click Apply.
After doing so, go to VPN>IPsec and click Save on that page. Then to make sure that config change is applied, do a full stop, then start (not just restart) of IPsec, or reboot the system to make sure it's really a clean start.
That's the only change in that timing that I see. It shouldn't be any worse at least, though for IKEv2 MOBIKE will kick in and drop tunnels if you have OpenVPN instances running and they reconnect.
Updated by Chris Buechler over 9 years ago
- Status changed from Confirmed to Feedback
- Target version changed from 2.2.1 to 2.2.2
Prefer old SAs, which is now gone in 2.2.1, definitely made up a part of still-outstanding issues here. interfaces_use seems to be responsible for some of the remainder, given Christian's description. That's disabled by default in 2.2.1 also.
Christian, since you have such a specific replicable case, please report back with findings.
Updated by tb o over 9 years ago
Sorry for not beeing that active here, forgot to watch this thread ;)
I will test this with the 2.2 RC device after upgrading to 2.2, I will report back soon.
Updated by tb o over 9 years ago
- File single_p2.PNG single_p2.PNG added
It looks like this fixed the issue for me. All of the vpn tunnels are still working (lifetime phase1 8h and phase2 1h).
Before the next day half of the vpn stopped working.
Only weird thing is that if looking under status-> ipsec some of the sa are multiple old and new sa (one example as screenshot).
Updated by tb o over 9 years ago
Feedback: with 2.2.1 the issue is also gone (for us).
I have updated several devices which we had to downgrade to 2.1.5 again to 2.2.1 and until now the problem has not reoccurred (with 20-30 vpn tunnels).
Only thing left are duplicated phase2 entries with ikev1 but that seems not affecting the vpn connection (at status page, see screenshot above).
Updated by Chris Buechler over 9 years ago
- Target version changed from 2.2.2 to 2.2.3
Updated by Chris Buechler over 9 years ago
- Status changed from Feedback to Resolved
the original issue in this ticket no longer exists in 2.2.1 and newer. The remaining multi-P2 issues are covered by #4665.