[Openswan dev] DPD issue with multiple tunnels between two peers

David McCullough David_Mccullough at securecomputing.com
Sun Jul 8 22:45:59 EDT 2007

Jivin Mark-Andre Hopf lays it down ...
> On Fri 06.07. 08:56, Michael Richardson wrote:
> >     Mark-Andre> Was the 'restart_by_peer' option problemtatic or
> >     Mark-Andre> developing a fix? I see 
> >  
> >   I don't know what a "restart_by_peer" option is.
> Oh, sorry. I just saw that 'restart_by_peer' was part of the OCF patch
>   ocf-openswan-v245rc6-20060331.diff
> (What had a feature like that to do in the OCF patch...?)

Nothing really,  just that we added the restart_by_peer option to
openswan,  and it got bundled up with the OCF work we did as well.

>  It causes Openswan do restart all connections to the same peer in case
> DPD becomes active. Without it, only the connection owning the active
> ISAKMP SA is restarted while the others remain dead until the keys
> expire.

I wasn't involved in the reasoning behind it's addition,  so I am not
an authority on it,  nor do I have an opinion on whether or not it's a
good idea :-)

Basically this has been carried across from the freeswan code that we
deploy on our VPN products.  This functionality was deemed important
enough that it would also be needed under Openswan.  We have been
using it for a long time.

I believe the changes are tied into the dynamic DNS changes that are
also part of the patch.  I can dig up more info if anyone is interested.


David McCullough,  david_mccullough at securecomputing.com,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org http://www.cyberguard.com

More information about the Dev mailing list