+ipsec_common_input: no key association found for SA

[Gabe]

> From: Bjoern A. Zeeb <bzeeb-lists at lists.zabbadoz.net>
> Subject: Re: +ipsec_common_input: no key association found for SA
> To: "Gabe" <nrml at att.net>
> Cc: freebsd-net at freebsd.org
> Date: Sunday, January 4, 2009, 3:24 AM
> 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 understand. I'm having to rebuild "box" (unrelated) so this will have to wait, I will definitely do it as mentioned above.

> > 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?
> 

They're i386. 

This is uname -a on "box":

FreeBSD box.domain.tld 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri Dec 12 07:11:30 PST 2008     root at box.domain.tld:/usr/obj/usr/src/sys/KERNEL  i386

This is uname -a on "box2":

FreeBSD box2.domain.tld 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #5: Fri Dec 26 01:48:31 PST 2008     root at box2.domain.tld:/usr/obj/usr/src/sys/KERNEL  i386

One thing I found to be interesting is that "box2" no longer spews out the ipsec_common_input message after I corrected the 'spdadd' lines. So perhaps this is related to the different kernel sources version.

Either way I'll report back once I'm finished rebuilding "box"