[strongSwan] charon often has two tunnels for one connection
wolfgang.walter at stwm.de
Fri Nov 12 22:15:00 CET 2010
thanks for your help and explanations.
On Thursday 11 November 2010, you wrote:
> No, this is not possible. If you prefer one side then set it to
> auto=start and the other side to auto=add.
Yes, I thought about that. But then a reboot of the side with auto=add would
not reestablish the tunnels.
I tried to work around by adding dpdaction=restart to the side which has
auto=start but that didn't work out.
I'll now try the following:
both sides with auto=add
then a small daemon which checks every minute or so
* if a connection is dead it restarts it if this router should be the
* which should be the initiator comes from a extra config file.
Probably I can solve another problem with this approach, too: spread the
rekeying steady over time. rekeyfuzz can't do that very well if most
connection have the same lifetime. You would need special "startup-fuzzy"
which is only used when a connection is started or must be rekeyed because the
IKE-SA is rekeyed and which modifies this first lifetime to anything beetween
several minutes to maximum lifetime.
Hmm, ipsec is hairy.
By the way: without strongswan we could not use ipsec and linux to build our
vpn. It is the only ike-solution which is stable and scales well. I really
> On 11/11/2010 11:35 PM, Wolfgang Walter wrote:
> > Hello Andreas,
> > On Thursday 11 November 2010, Andreas Steffen wrote:
> >> Hello Wolfgang,
> >> if you define auto=start on both ends of the connection then it is
> >> normal that two IKE_SAs and two CHILD_SAs are established. As you
> >> can see each end is the initiator designated by an asteris symbol
> >> ('*'):
> >>> LEO15D-to-TUMBER_D: IKE SPIs: 49aee81a1e459923_i
> >> dec7d37f60b96152_r*, public key reauthentication in 103 minutes
> >>> LEO15D-to-TUMBER_D: IKE SPIs: 52e9261978df059c_i*
> >> fc5a10078fb78d74_r, public key reauthentication in 95 minutes
> >> The IKEv2 standard allows for this situation, so there is nothing
> >> special about it. In the past there were some race condition
> >> problems when both ends rekeyed at the same time but most of the
> >> issues have been fixed in the latest releases.
> > Yes.
> > My problem is that - once two are established - they remain as both are
> > rekeyed regulary. This doubles the number of rekeying events. Would it be
> > possible to have a sort of a "second-class"-field:
> > conn LEO15D-to-TUMBER_D
> > leftfavour=yes
> > which would mean:
> > if a second child-sa gets established close that one which was initiated
> > right
> >> Regards
> >> Andreas
> > Regards,
> Andreas Steffen andreas.steffen at strongswan.org
> strongSwan - the Linux VPN Solution! www.strongswan.org
> Institute for Internet Technologies and Applications
> University of Applied Sciences Rapperswil
> CH-8640 Rapperswil (Switzerland)
Anstalt des öffentlichen Rechts
More information about the Users