Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 4 Jan 2009 11:24:58 +0000 (UTC)
From:      "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
To:        Gabe <nrml@att.net>
Cc:        freebsd-net@freebsd.org
Subject:   Re: +ipsec_common_input: no key association found for SA
Message-ID:  <20090104110430.I45399@maildrop.int.zabbadoz.net>
In-Reply-To: <186728.8993.qm@web83802.mail.sp1.yahoo.com>
References:  <186728.8993.qm@web83802.mail.sp1.yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 4 Jan 2009, Gabe wrote:

Hi,

>>> Ok, can you try running the following script and see
>> if the
>>> output
>>> times match your racoon restarts or the log entries?

You hadn't answered that question to correlate the tcpdump with racoon
restarts and kernel log entries.

If you do that, you may want to run the script for two hours or four
to actually see more changes than just the initial one.

Check the syslog timestamps in the logfile where your kernel messages
go to (might be /var/log/messages) for the ipsec_common_input lines.
Perhaps grep upfront before startung the script to be sure that they
are there.


> I'm still unable to find the cause for this. Does anyone know what the above output is referring to?

I think David DeSimone  had last explained it to you:
http://lists.freebsd.org/pipermail/freebsd-net/2008-December/020611.html

Maybe it would be time to read the RFC now; I'll try it in my own
words again and shorter.

Your IPsec Policy makes your racoons negotiate a Security Assosiaction
for some parameters (keys, lieftime, ..). There will be one for each
direction. One thing negotiated is the security policy index, the
number we are tracing. This 'number' is put into each packet one of the
boxes send encrypted to the other for the given direction.

What your kernel tells you is that the number in the packet received
does not make sense to the box receiving it. Let's say the SPI received in
the packet from the other box is unknown on the receiver side. That's
why the kernel complains.
Without the proper SPI the kernel will not be able to find the proper
other parameters for this packet, and thus will not be able to decrypt
the packet.


What we are trying to find out at the moment is to identify where
exactly the wrong SPI is coming from. This could be:
- whatever the boxes negotiated  gets out of sync
- a patch like the NAT-T patch could corrupt the packet
- a software bug in where the kernel or racoon
- ...

To narrow this down from "everywhere" to "here" it is important to see
where the values match, where not and when they do not match - thus
correlating information from the time racoon gets restarted, the
kernel prints the log message and what tcpdump is showing. It's
important to get all this information for the same problematic moment,
timestamped. If one is missing it's like a 1000 pieces puzzle with
only 600 pieces included.

One more question that hadn't been asked so far - what architectures
(i386, amd64, sparc, arm, ..) are box and box2 and which version of
freebsd are they running; I assume they are both on freebsd?


/bz

-- 
Bjoern A. Zeeb                      The greatest risk is not taking one.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090104110430.I45399>