From owner-freebsd-net@FreeBSD.ORG Sun Jan 4 11:25:12 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 8E32D106566B for ; Sun, 4 Jan 2009 11:25:12 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 36D438FC14 for ; Sun, 4 Jan 2009 11:25:12 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 261F041C62D; Sun, 4 Jan 2009 12:25:11 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id kWrAWi-84CyF; Sun, 4 Jan 2009 12:25:10 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id B6C9B41C616; Sun, 4 Jan 2009 12:25:10 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 5DA934448DD; Sun, 4 Jan 2009 11:24:59 +0000 (UTC) Date: Sun, 4 Jan 2009 11:24:58 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Gabe In-Reply-To: <186728.8993.qm@web83802.mail.sp1.yahoo.com> Message-ID: <20090104110430.I45399@maildrop.int.zabbadoz.net> References: <186728.8993.qm@web83802.mail.sp1.yahoo.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 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 11:25:12 -0000 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'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? /bz -- Bjoern A. Zeeb The greatest risk is not taking one.