<div dir="ltr">Thank you Tobias, Option 1 (ignore a phase1 delete) worked for me.<div><br></div><div>regards,</div><div>SK<br><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 15, 2015 at 12:43 AM, Tobias Brunner <span dir="ltr"><<a href="mailto:tobias@strongswan.org" target="_blank">tobias@strongswan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
> Are IKEv1s are expected to break all connections before making a new one?<br>
> Or<br>
> Are they expected to make a new one before breaking the old one.<br>
<br>
</span>The latter, but that's just how charon expects it.  ISAKMP as such does<br>
not require a Ph1 SA between peers that have Ph2 SAs (see [1]).<br>
<span class=""><br>
> 1. Ignore an Phase 1 delete if it still has phase2s. This is for IKEv1<br>
> only since we are testing with ikev1 firewalls only.<br>
> 2. Instead of silently deleting Phase2s, do a proper delete that sends<br>
> out a DELETE to the other side. Would this be difficult to implement?<br>
<br>
</span>2 will only work if the SAs are recreated again automatically (e.g. if<br>
you use auto=route).  But it's definitely more difficult to implement.<br>
So I'd try 1 first.<br>
<br>
Regards,<br>
Tobias<br>
<br>
[1] <a href="https://tools.ietf.org/html/draft-jenkins-ipsec-rekeying-06#section-3.3" target="_blank">https://tools.ietf.org/html/draft-jenkins-ipsec-rekeying-06#section-3.3</a><br>
<br>
</blockquote></div><br></div>