[Openswan dev] Patch for review

[Tuomo Soini]

Herbert Xu wrote:
> On Mon, Apr 26, 2010 at 01:30:04PM -0400, Paul Wouters wrote:
>> On Mon, 26 Apr 2010, D. Hugh Redelmeier wrote:
>>
>>> | Real problem with the initate code is that netkey does generate acquires
>>> | even when you have permanent, working ipsec tunnel up and running and
>>> | packets are traveling tunnel.
>>>
>>> That sounds odd.  Why does it do that?
>>>
>>> (Note: I know very little about netkey so this may be a very naive
>>> question.)
>> We don't know. I assume this is a kernel bug. Perhaps Herbert can tell us
>> more?
> 
> I suspect that was either a bug or a misconfiguration.
> 
> If you keep getting acquires then that means your tunnel simply
> can't transmit.  Ignoring the acquires isn't going to make the 
> tunnel magically work :)

Unfortunately that's exactly how it seem to be: Tunnel does work but we
still get acquires all the time I guess we need to add more debugging to
get data for acquires with state CK_PERMANENT.

It seems like xfrm is generating acquire for every unreplied state in
connection tracking table because this only happens if there are lots of
packets with UNREPLIED state, eg udp traffic which are not answered, ever.

We use special application where one end of the tunnel is sending other
end udp packets which are never repied.

This causes continous acquires. If code allows acquire to generate new
quick mode for every acquire we get like 60 tunnels in minute. And
initial tunnel seem to work. If we ignore acquires for existing tunnel
communication tunnel seem to just work.

I wonder if we generate different policy with openswan-2.6.25 than
openswan-2.6.24.

-- 
Tuomo Soini <tis at foobar.fi>
Foobar Linux services
+358 40 5240030
Foobar Oy <http://foobar.fi/>