From owner-freebsd-net@FreeBSD.ORG Sun Jan 4 12:11:28 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6936C1065678 for ; Sun, 4 Jan 2009 12:11:28 +0000 (UTC) (envelope-from nrml@att.net) Received: from web83809.mail.sp1.yahoo.com (web83809.mail.sp1.yahoo.com [69.147.85.81]) by mx1.freebsd.org (Postfix) with SMTP id 55EA78FC16 for ; Sun, 4 Jan 2009 12:11:28 +0000 (UTC) (envelope-from nrml@att.net) Received: (qmail 90290 invoked by uid 60001); 4 Jan 2009 12:11:27 -0000 X-YMail-OSG: Yoe5rjcVM1lF5oOTJhSf.S2iWmG4ziiZ.jcGGoQXt6Y7oKjgc4lleoIsnyAzydMlj2FrU6LUtotnzn1mkG5FMgZv7wF_P_NPktRKXMxW6cJpsYxQY0AUTvin.7PuccQpoI5o3qMQZWmIMWfDu2viO8kRSesLASc.4XEOJdmdKXZof9igfhyQ2w9br0R7rtQATrKzUEpnt99pBXSyM_emeyRDYOkW Received: from [69.43.143.172] by web83809.mail.sp1.yahoo.com via HTTP; Sun, 04 Jan 2009 04:11:27 PST X-Mailer: YahooMailWebService/0.7.218.2 Date: Sun, 4 Jan 2009 04:11:27 -0800 (PST) From: Gabe To: "Bjoern A. Zeeb" In-Reply-To: <20090104110430.I45399@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <881287.90275.qm@web83809.mail.sp1.yahoo.com> Cc: freebsd-net@freebsd.org Subject: Re: +ipsec_common_input: no key association found for SA X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nrml@att.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2009 12:11:28 -0000 > From: Bjoern A. Zeeb > Subject: Re: +ipsec_common_input: no key association found for SA > To: "Gabe" > 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"