[Swan] dpd question

[Kostya Vasilyev]

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
kman at fastmail.com

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