Project

General

Profile

Actions
Copy link

Bug #3981

closed

strongswan "gets crazy" after a few reloads, wipes SAD and doesn't remove old SPD

Added by Chris Buechler about 10 years ago. Updated about 10 years ago.

Status:
Resolved
Priority:
Very High
Assignee:
Ermal Luçi
Category:
IPsec
Target version:
2.2
Start date:
11/03/2014
Due date:
% Done:

0%

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

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.

Actions
Copy link
 #2

Updated by Chris Buechler about 10 years ago

  • Status changed from New to Resolved

something was fixed that resolved this

Actions
Copy link
 #3

Updated by Chris Buechler about 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.

Actions
Copy link
 #4

Updated by Ermal Luçi about 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?

Actions
Copy link
 #5

Updated by Chris Buechler about 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.

Actions
Copy link
 #6

Updated by Chris Buechler about 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.

Actions
Copy link
 #7

Updated by Ermal Luçi about 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.

Actions
Copy link
 #8

Updated by Chris Buechler about 10 years ago

  • Status changed from Feedback to Resolved

fixed

Actions
Copy link

Also available in: Atom PDF