+ipsec_common_input: no key association found for SA

[Gabe]

> From: Gabe <nrml at att.net>
> Subject: Re: +ipsec_common_input: no key association found for SA
> To: "Bjoern A. Zeeb" <bzeeb-lists at lists.zabbadoz.net>
> Cc: freebsd-net at freebsd.org
> Date: Sunday, January 4, 2009, 4:11 AM
> > 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"

Well, I can't continue to try and figure this out. The boxes where this is occurring are live production boxes and well I need to figure out a better solution that's a little more intuitive. So it seems that just like many other freebsd users out there with IPSec and the NAT-T patch this will remain unanswered.

Thanks Bjoern and everyone who answered.

Cheers

/gabe