[Openswan Users] Missing route for an established IPSEC connection.

[Paul Wouters]

On Thu, 23 Feb 2006, John Rouillard wrote:

> > > 000 192.168.1.97/32:0 -17-> 192.168.8.233/32:0 => %hold 0 %acquire-netlink
> >
> > This was a bug in NETKEY.
>
> >From my googling it looks like NETKEY is just the name for the native
> 2.6 kernel ipsec implementation. Is this correct?  Is it indicated by
> the presence of the esp4 and ah4 modules rather then the ipsec module?

That's correct. We do not call it 'native 2.6' because it is also back
ported to 2.4 kernels, and for 2.4 kernels the 'native' stack was klips,
so using the word native is just too confusing.

> These systems had been running for months without problem until Monday
> evening.  Also its weird that I am seeing this for only one of the 4
> ipsec tunnels. Do you have any details on this bug?

There might be some more details in the bugtracker on bugs.openswan.org
if you search for acquire-netlink (or check the mailinglist).

> Would rebooting one or both endpoints clear the problem? Maybe

That would probably help, especially if you normally don't see this
behaviour.

> Also just to verify this is a symptom that is consistent with the
> failure to pass traffic across the link? If these messages go away so
> should the link problem?

Yes, the %hold means that packets are caught but there is no IPsec
tunnel to send them, while there is an ipsec policy for them, so
they are not allowed to go out plaintext either.

> > Either upgrade the netkey based kernel, or upgrade openswan to 2.4.x
> > which has a workaround for this.
>
> I will look into this, but I would prefer to minimize the changes
> needed to these production systems, especially since they are remote
> systems.

Then just try rebooting I guess.

Paul