Bug #3981
closedstrongswan "gets crazy" after a few reloads, wipes SAD and doesn't remove old SPD
0%
Description
This is a recent regression in 2.2. diag_ipsec_spd.php shows "No IPsec security associations" when there are active, functional SAs. 'setkey -D' returns no output, which is where ipsec_dump_sad() pulls.
Updated by Chris Buechler almost 10 years ago
- Status changed from New to Resolved
something was fixed that resolved this
Updated by Chris Buechler almost 10 years ago
- Subject changed from diag_ipsec_spd.php blank to strongswan "gets crazy" after a few reloads, wipes SAD and doesn't remove old SPD
- Status changed from Resolved to Confirmed
Actually this is hit and miss, but it's the same root issue as #3960 it appears. Changed subject to the best description Renato and I have come up with from what we know about it now.
Updated by Ermal Luçi almost 10 years ago
- Status changed from Confirmed to Feedback
I cannot reproduce it on my side but for sure it was reloading secrets/crl/ca/cert's but was not realoding the configuration hence probably there were misunderstandings.
Can you tell me how to reproduce or retry again after my commit with latest gitsync?
Updated by Chris Buechler almost 10 years ago
One way to replicate is changing the P2 local and/or remote subnet on a functional site to site VPN. Check SAD and SPD, if both are correct, go back and try changing it again. It doesn't happen every time, but it happens roughly half the time maybe. Try that 2 or 3 times and you'll be able to trigger it.
Updated by Chris Buechler almost 10 years ago
- Status changed from Feedback to Confirmed
- Assignee set to Ermal Luçi
this is pretty easily replicable. Log into 22vpntest, VPN>IPsec. Edit one of the "cmb home site to site" P2s, for instance change 10.0.64.0 to 10.0.164.0. Afterwards you end up with both.
# setkey -DP | grep 10.0.64 10.0.64.0/24[any] 172.29.0.0/21[any] any 172.29.0.0/21[any] 10.0.64.0/24[any] any # setkey -DP | grep 10.0.164 10.0.164.0/24[any] 172.29.0.0/21[any] any 172.29.0.0/21[any] 10.0.164.0/24[any] any
If it doesn't happen on the first attempt, try changing it again to something different. It seems to happen at least half the time, it's easily replicable.
Updated by Ermal Luçi almost 10 years ago
- Status changed from Confirmed to Feedback
This seems a non issue since the old SPD will stay there until the SA related to them be alive.
As long as the old SA will timeout the SPD will be removed.