Bug #983
Rekeying failure in 5.3.1
Start date:
04.06.2015
Due date:
Estimated time:
Affected version:
5.3.1
Resolution:
Duplicate
Description
Since I upgraded to strongSwan 5.3.1, my machine sometimes fails to renew its CHILD_SA with a gateway running strongSwan 5.2.1. From the logs, I see that the gateway sends a CREATE_CHILD_SA request with REKEY_SA, and it fails with the following log (anonymized):
Jun 04 10:05:13 rw charon-systemd[875]: received packet: from GW-IP-ADDRESS[4500] to 192.168.1.56[4500] (765 bytes)
Jun 04 10:05:13 rw charon-systemd[875]: parsed CREATE_CHILD_SA request 0 [ N(REKEY_SA) SA No KE TSi TSr ]
Jun 04 10:05:13 rw charon-systemd[875]: CHILD_SA gw-lan{10} established with SPIs c922c845_i c28bf321_o and TS RW-VIP-ADDRESS/32 === GW-REMOTE-LAN/16
Jun 04 10:05:13 rw charon-systemd[875]: generating CREATE_CHILD_SA response 0 [ SA No KE TSi TSr ]
-> Jun 04 10:05:13 rw charon-systemd[875]: encrypting encrypted payload failed, no IV or padding
Jun 04 10:05:16 rw charon-systemd[875]: creating acquire job for policy RW-VIP-ADDRESS/32[udp/36475] === GW-REMOTE-HOST/32[udp/60001] with reqid {2}
Jun 04 10:05:16 rw charon-systemd[875]: initiating IKE_SA gw[6] to GW-IP-ADDRESS
When that happens the SA completely disappears, and since I use a trap policy it automatically gets reinitiated (but the SA is still alive on the gateway, so the tunnel is down until the remote SA goes away).
So far I haven't seen that with another gateway I'm also permanently connected to and which was upgraded to 5.3.1 at the same time as the client.
Related issues
History
#1 Updated by Tobias Brunner about 7 years ago
- Is duplicate of Bug #980: iv-gen issue... added
#2 Updated by Tobias Brunner about 7 years ago
- Status changed from New to Closed
- Resolution set to Duplicate
#3 Updated by Tobias Brunner about 7 years ago
- Tracker changed from Issue to Bug
- Target version set to 5.3.2