Date: Wed, 7 Jan 2009 06:13:45 -0800 (PST) From: Gabe <nrml@att.net> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: freebsd-net@freebsd.org Subject: Re: +ipsec_common_input: no key association found for SA Message-ID: <227893.30747.qm@web83803.mail.sp1.yahoo.com> In-Reply-To: <881287.90275.qm@web83809.mail.sp1.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> From: Gabe <nrml@att.net> > Subject: Re: +ipsec_common_input: no key association found for SA > To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> > Cc: freebsd-net@freebsd.org > Date: Sunday, January 4, 2009, 4:11 AM > > From: Bjoern A. Zeeb > <bzeeb-lists@lists.zabbadoz.net> > > Subject: Re: +ipsec_common_input: no key association > found for SA > > To: "Gabe" <nrml@att.net> > > Cc: freebsd-net@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@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?227893.30747.qm>