Bug #4268
closed
changes in strongswan config don't apply to SAD or SPD
Added by Chris Buechler almost 10 years ago. Updated over 8 years ago.
0%
Description
Doesn't appear we've opened a ticket to address this yet. strongSwan's behavior of not updating the SAD is going to generate complaints and cause issues for those accustomed to the SAD being updated when the IPsec config changes.
Updated by Ermal Luçi almost 10 years ago
I do not expect there to be issues from this.
The SAD is there but the policies(SPD) are not so there is nothing that can use that SA!
Any real issue from this or just a diagnostic misdirection?
Updated by Ermal Luçi almost 10 years ago
- Status changed from Confirmed to Feedback
For me this should be closed.
Setting in feedback for now.
Updated by Chris Buechler almost 10 years ago
- Status changed from Feedback to Confirmed
- Target version changed from 2.2.1 to 2.2.2
It causes a wide range of problems for people. We've already seen several people report IPsec changes not applying because of this reason. This is opposite the behavior we've always had, and opposite essentially every similar product.
That said, it's not going to make the short list for 2.2.1.
Updated by Chris Buechler over 9 years ago
- Target version changed from 2.2.2 to 2.2.3
Updated by Ermal Luçi over 9 years ago
- Status changed from Confirmed to Feedback
There is a commit done on how charon daemon was restarted.
Now it goes and signals starter which does the right thing even for SAs.
Updated by Chris Buechler over 9 years ago
- Subject changed from changes in strongswan config don't apply to already-active SAs to changes in strongswan config don't apply to SAD or SPD
- Status changed from Feedback to Confirmed
- Assignee set to Ermal Luçi
- Priority changed from Normal to High
- Target version changed from 2.2.3 to 2.3
- Affected Version changed from 2.2 to 2.2.x
no change. SPD and SAD both remain in place. For example, bring up an IPsec connection of any type. Verify its SAD and SPD. Then change the local and remote networks on the P2. You'll have the old SAs and SPD entries there, plus the new ones. moving to 2.3 since it's not critical for 2.2.3.
Updated by Ermal Luçi over 9 years ago
They will not go away from what i recall until the SA expires.
But the new SPD will be used for new packets.
Updated by Jim Thompson over 9 years ago
- Assignee changed from Ermal Luçi to Renato Botelho
reassigned to renato
Updated by Jim Thompson about 9 years ago
- Assignee changed from Renato Botelho to Matthew Smith
- Priority changed from High to Normal
I'm not sure I see this as a bug. I don't think you >want< the behavior that SPD and SAD can change. Rather, you withdraw them and install new ones, or you wait for the old ones to expire.
Reassigned to Matt, who will determine what is reasonable.
It's also been 10 months, and I don't hear the predicted complaints.
Updated by Jim Thompson almost 9 years ago
- Assignee changed from Matthew Smith to Chris Buechler
11 months now, I don't hear the complaints. Chris opened this. i will close it at 12 months if he doesn't re-engage.
Updated by Jim Thompson almost 9 years ago
- Tracker changed from Bug to Feature
- Priority changed from Normal to Very Low
Changed to low-priority feature (was high priority bug) because this has been open for a year with no action.
Updated by Jim Thompson almost 9 years ago
- Target version changed from 2.3 to Future
- Affected Architecture All added
- Affected Architecture deleted (
)
Updated by Chris Buechler over 8 years ago
- Tracker changed from Feature to Bug
- Status changed from Confirmed to Closed
- Target version deleted (
Future) - Affected Architecture All added
when this started, it was a much bigger issue. The worst of it was fixed, but the remaining part with the SAD is still an issue and still generates support issues. Opened #6624 for that given the history here largely isn't applicable