Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 4 Jan 2009 04:11:27 -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:  <881287.90275.qm@web83809.mail.sp1.yahoo.com>
In-Reply-To: <20090104110430.I45399@maildrop.int.zabbadoz.net>

next in thread | previous in thread | raw e-mail | index | archive | help
> 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"



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