https://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162016-07-26T13:37:08ZpfSense bugtrackerpfSense - Bug #6624: changes in IPsec config should down the connectionhttps://redmine.pfsense.org/issues/6624?journal_id=284352016-07-26T13:37:08ZJim Thompsonjim@netgate.com
<ul><li><strong>Assignee</strong> set to <i>Renato Botelho</i></li></ul> pfSense - Bug #6624: changes in IPsec config should down the connectionhttps://redmine.pfsense.org/issues/6624?journal_id=310302017-02-01T05:51:07ZLars Pedersenthacaleb@gmail.com
<ul></ul><p>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.</p> pfSense - Bug #6624: changes in IPsec config should down the connectionhttps://redmine.pfsense.org/issues/6624?journal_id=552552021-07-26T13:41:37ZJim Pingle
<ul><li><strong>Has duplicate</strong> <i><a class="issue tracker-1 status-11 priority-4 priority-default closed" href="/issues/11900">Bug #11900</a>: IPsec tunnels remain active after disabling</i> added</li></ul> pfSense - Bug #6624: changes in IPsec config should down the connectionhttps://redmine.pfsense.org/issues/6624?journal_id=552562021-07-26T13:47:56ZJim Pingle
<ul><li><strong>Assignee</strong> changed from <i>Renato Botelho</i> to <i>Jim Pingle</i></li><li><strong>Affected Version</strong> deleted (<del><i>2.2.x</i></del>)</li></ul><p>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.</p>
<p>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.</p>
<p>The strongSwan syntax mentioned above is wrong since we have moved to swanctl format. Clear affected SAs with <code>swanctl --terminate</code> as needed, or use <code>ipsec_terminate()</code> which will be present once my current work is completed.</p> pfSense - Bug #6624: changes in IPsec config should down the connectionhttps://redmine.pfsense.org/issues/6624?journal_id=553742021-08-02T12:08:47ZJim Pingle
<ul></ul><p>This is going to take a bit more thought yet. Some factors make it more complicated than it seems on the surface:</p>
<ul>
<li>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.</li>
<li>Deleting or disabling a P1, we can terminate the old one by name</li>
<li>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</li>
<li>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</li>
<li>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</li>
<li>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.</li>
</ul>
<p>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.</p> pfSense - Bug #6624: changes in IPsec config should down the connectionhttps://redmine.pfsense.org/issues/6624?journal_id=607522022-04-27T07:40:54ZViktor Gurov
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-1 priority-4 priority-default" href="/issues/13102">Bug #13102</a>: Deleting an IPSec tunnel doesn't destroy the SA (SADs/SPDs), causes crash in status_ipsec.php</i> added</li></ul>