[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openswan-users
Subject:    Re: [Openswan Users] Unstable behavior with 2 tunnels connecting the same sites
From:       "Greg Scott" <GregScott () Infrasupport ! com>
Date:       2010-07-16 3:54:45
Message-ID: 925A849792280C4E80C5461017A4B8A27D7E57 () mail733 ! InfraSupportEtc ! com
[Download RAW message or body]

What are %acquire messages?  I wonder if I can put in some iptables rules to block \
the ones I don't like?

- Greg


-----Original Message-----
From: Paul Wouters [mailto:paul@xelerance.com] 
Sent: Wednesday, July 14, 2010 11:11 AM
To: Greg Scott
Cc: users@openswan.org; dev@openswan.org
Subject: Re: [Openswan Users] Unstable behavior with 2 tunnels connecting the same \
sites

On Wed, 14 Jul 2010, Greg Scott wrote:

> Something unhealthy is going on with configs that have multiple tunnels connecting \
> the same sites. 

> Every once-in-a-while, one or more of these tunnels decides to go out to lunch.  \
> This is usually when there¢s a telcom interruption.  IPSEC is supposed to hook both \
> sites back up after the telecom comes back online, but this doesn¢t always work \
> here.  The only solution is to manually restart ipsec on one side or the other. 

> When the problem is happening, I see lots of messages coming into /var/log/secure.  \
> Here is a sample:

> Jul 14 08:00:00 localhost pluto[23465]: initiate on demand from 175.10.0.1:8 to \
> 175.9.1.35:0 proto=1 state: fos_start be

This is the netkey bug I posted about to dev@openswan.org yesterday. This bug \
appeared when David applied some KLIPS rekey patches a month ago :(

We have not been able to address it. It is related to NETKEY sending an endless \
stream of %acquire messages.

The quick fix is to use KLIPS. If you don't need NAT-T, which it seems you don't, it \
should be a relatively straightforward compile.

export KERNELSRC=/usr/src/kernels/linux-2.6.xxxx/
make module module_install

and set protostack=klips in ipsec.conf

Paul


[prev in list] [next in list] [prev in thread] [next in thread]