[Swan] DPD Bug

[Paul Wouters]

On Fri, 22 Feb 2013, Nick Howitt wrote:

> I think I've just hit a DPD bug. I have dpdaction set to restart_by_peer as I 
> use FQDN's in my conn definition and I want to force the conn definition to 
> be re-read to re-evaluate the FQDN's.

> Feb 19 09:37:39 server pluto[25698]: "MumIn" #415: DPD: No response from peer 
> - declaring peer dead
> Feb 19 09:37:39 server pluto[25698]: "MumIn" #415: DPD: Restarting all 
> connections that share this peer
> Feb 19 09:37:40 server pluto[25698]: "MumIn" #415: terminating SAs using this 
> connection
> Feb 19 09:37:40 server pluto[25698]: "MumIn" #426: deleting state 
> (STATE_QUICK_R2)
> Feb 19 09:37:40 server pluto[25698]: "MumIn" #424: deleting state 
> (STATE_QUICK_R2)
> Feb 19 09:37:40 server pluto[25698]: "MumIn" #415: deleting state 
> (STATE_MAIN_R3)
> Feb 19 09:37:40 server pluto[25698]: "MumIn" #428: deleting state 
> (STATE_QUICK_R2)
> Feb 19 09:37:40 server pluto[25698]: "MumIn" #427: deleting state 
> (STATE_MAIN_R3)

Looks like many racing instances of the same conn?

> Feb 19 09:39:16 server pluto[25698]: "MumIn" #431: STATE_QUICK_R2: IPsec SA 
> established tunnel mode {ESP=>0xe7284fac <0x8be43449 xfrm=AES_256-HMAC_SHA1 
> NATOA=none NATD=none DPD=enabled}
> Feb 19 09:45:12 server pluto[25698]: pending Quick Mode with 86.14.142.156 
> "MumIn" took too long -- replacing phase 1
> Feb 19 09:45:12 server pluto[25698]: "MumIn": terminating SAs using this 
> connection
> Feb 19 09:45:12 server pluto[25698]: "MumIn" #429: deleting state 
> (STATE_MAIN_I1)
>
> The problem I have is that the conn is defined with "auto=add" so why am I 
> seeing a "Feb 19 09:37:40 server pluto[25698]: "MumIn" #429: initiating Main 
> Mode" message which you should only get with auto=start.

Do you hav rekey=no as well? If so, then it looks like a bug.

Paul