[Openswan dev] DPD issue with multiple tunnels between two pe ers

Venkat Yekkirala vyekkirala at TrustedCS.com
Mon Jul 9 12:15:11 EDT 2007

>     Mark-Andre>  It causes Openswan do restart all connections to the
>     Mark-Andre> same peer in case DPD becomes active. Without it, only
>     Mark-Andre> the connection owning the active ISAKMP SA is 
> restarted
>     Mark-Andre> while the others remain dead until the keys expire.
>   2.5.0 has the same functionality.  It does DPD on the phase 
> 1, not the
> phase 2, performing whatever actions are necessary on all phase 2s.

But seems like only on all phase 2s for the connection owning the
phase 1 in question. Any phase 2s belonging to other connections
to the same peer (with the phase 1 SA not being around) could be
left lying around until they expire.

I am running into a similar problem, but with the DPD action set
to "clear". When a peer goes down unexpectedly, DPD on the phase 1
and RELATED phase 2s get cleared fine, but I still have other phase 2s
belonging to a different connection to the same peer lying around
without a phase 1, resulting in the follwing:

Jul  3 15:27:27 DC1 pluto[5317]: "tc-to-dc"[46] #553: DPD:
Serious: could not find newest phase 1 state

I am a newbie to openswan and I have the following questions in this

1. Openswan seems to be negotiating a Phase 1 each for each connection
   even when the connections are all to the same peer. Is this the
   expected behaviour?

2. I seem to notice that one of the 2 phase 1s to the same peer is deleted
   after some time, causing the remaining phase 1 to be used to negotiate
   phase 2s for either connection. Is this the expected behaviour as well?



More information about the Dev mailing list