I see, yes it makes sense to keep trying "forever" if this side initiates.
Now I've set ikev2=insist and see this in the logs:
pluto[8407]: "mytunnel" #7: STATE_V2_IPSEC_R: IPsec SA established transport
mode {ESP=>0x0530016d <0x1813ca67 xfrm=AES_CBC_128-HMAC_SHA2_256_128 NATOA=none
NATD=none DPD=active}
pluto[8407]: "mytunnel" #5: suppressing retransmit because superseded by #7
try=1. Drop this negotitation
pluto[8407]: "mytunnel" #5: deleting state (STATE_PARENT_I1) and NOT sending
notification
... which looks perfect - I guess it matches an established ( by the client in
the meanwhile) connection and stops trying to initiate.
No more attempts to initiate v1 anymore either.
Thanks!
--
Kostya Vasilyev
[email protected]
On Fri, Feb 1, 2019, at 9:14 PM, Paul Wouters wrote:
> On Fri, 1 Feb 2019, Kostya Vasilyev wrote:
>
> > Oh and maybe it wasn't "connection going away" - maybe it was the server
> > trying to establish the initial connection.
> >
> > It's using IKEv1 - but the other side it set to use IKEv2 only.
> >
> > In fact the connection is already up (using IKEv2).
> >
> > Could this be the reason?
> >
> > In any case, how do I stop these endless connection attempts?
>
> If you have auto=start then the goal is to always be up. So even if
> DPD fails, the connection will attempt to be restarted again.
>
> If you have auto=add but issued ipsec auto --up the same applies.
>
> The same connection should not be up with ikev2 and be trying with
> ikev1.
>
> I'm not sure why you would want it to stop trying, but you can do
> that by setting keyingtries= to non-zero.
>
> Paul
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
