Bug #6624
open
changes in IPsec config should down the connection
Added by Chris Buechler over 8 years ago.
Updated over 3 years ago.
Description
The fact that strongswan doesn't take down an established connection after changing the config has lead to a number of support issues and user complaints. racoon would drop any existing connections upon changing of that connection's config. Many support cases and forum threads of changes not being applied have this as the root cause. Usually either where a config mismatch was created, but not realized until hours later when the existing expires, or after having added or removed networks with IKEv2 which don't work until manually disconnecting the connection on the status page.
Just doing an 'ipsec down conX' for the connection when the config is changed will address.
- Assignee set to Renato Botelho
As a sidenote: When using IPsec mobile clients with PSK keys it would be preferred not to take the entire IPsec service down when adding a new PSK key. Currently the ipsec service does nothing when adding new keys and we have to execute "ipsec rereadsecrets". So a solution where adding PSK keys and afterwards call "ipsec rereadsecrets" would be nice instead of all connected mobile clients are kicked out every time a new user is added.
- Has duplicate Bug #11900: IPsec tunnels remain active after disabling added
- Assignee changed from Renato Botelho to Jim Pingle
- Affected Version deleted (
2.2.x)
This should be more manageable once my current work is done. The P2 connection IDs will be more predictable and then when making changes which affect a specific P1 or P2 the appropriate entries can be terminated as needed.
Doing this in every change could be overkill, though, but if we limit it to certain events then some settings changes could be missed. Definitely needs done for deletes at least.
The strongSwan syntax mentioned above is wrong since we have moved to swanctl format. Clear affected SAs with swanctl --terminate as needed, or use ipsec_terminate() which will be present once my current work is completed.
This is going to take a bit more thought yet. Some factors make it more complicated than it seems on the surface:
- For any of the below cases, we'd need to setup a queue of items which need action on apply, since the old P2 info would be gone before the apply is run and we can't surprise users by terminating the P2 before they click apply.
- Deleting or disabling a P1, we can terminate the old one by name
- For IKEv1 and IKEv2+Split Connections, deleting or disabling a P2 would be a simple case of terminating the old P2 by its old name
- For IKEv1 and IKEv2+Split Connections, editing a P2 is similar to the first case of deleting, we could terminate the old and maybe initiate again
- For IKEv2 it gets more complicated as in either case it would involve terminating the only P2 and maybe initiating it again which would be potentially disruptive
- Doing the terminate and initiate actions would be contingent on IPsec being enabled and running, and would slow down the delete and apply processes. Even slower if we had to fetch the status first to see if they're connected before taking action.
Rather than taking automatic action, we could inform the user that the old entries may still be active and direct the user to the status page to manually perform the disconnect.
- Related to Bug #13102: Deleting an IPSec tunnel doesn't destroy the SA (SADs/SPDs), causes crash in status_ipsec.php added
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by Viktor Gurov