[Openswan dev] DPD issue with multiple tunnels between two pe ers
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
> 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: "tc-to-dc" 10.1.20.119 #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
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