[strongSwan] IKEv1 SA renewals and updated configuration

Noel Kuntze noel.kuntze+strongswan-users-ml at thermi.consulting
Thu Mar 22 23:35:06 CET 2018


Hello,

What you're seeing is expected. Already existing IKE SAs and CHILD SAs use the settings that they were established with.

Kind regards

Noel

On 22.03.2018 16:09, Rich Lafferty wrote:
> Hi all,
>
> Some background: In migrating our fleet from Racoon to Strongswan I discovered an interop bug where, with fragmentation enabled, Racoon sends fragmented IKEv1 packets which strongSwan is unable to decrypt. I discovered that the issue goes away if IKE fragmentation is disabled, and since we’re using PSK I’m confident that our IKE packets will be small enough to safely disable it, so I added `fragmentation = no` to all of our (swanctl-based) IKE connections on the StrongSwan side.
>
> On to my actual question…
>
> I discovered that while _new_ IKE SAs correctly do not advertise fragmentation, _renewals_ of already-established IKE SAs continue to use the same settings that they were established with (i.e. fragmentation is advertised and enabled).
>
> What I expected is that after a `swanctl --load-all`, the next IKE SA negotiation would use the new settings, so that the change could be rolled out gradually and invisibly as IKE SAs expire.
>
> Could someone more familiar with this verify that this is expected behaviour? Is there any way to tell strongSwan to use new configuration the next time an IKE SA is due for renewal, rather than interrupting the existing SA? (Later, I hope to migrate to a better encryption suite and was hoping to roll it out the same way without hard restarts of SAs.)
>
> Thanks,
> -Rich

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180322/57f8c5bd/attachment.sig>


More information about the Users mailing list