From owner-freebsd-net@FreeBSD.ORG Fri Jan 27 09:36:52 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E196E16A422 for ; Fri, 27 Jan 2006 09:36:52 +0000 (GMT) (envelope-from subscriber@osk.com.ua) Received: from gandalf.osk.com.ua (osk.com.ua [195.5.17.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B03B43D45 for ; Fri, 27 Jan 2006 09:36:51 +0000 (GMT) (envelope-from subscriber@osk.com.ua) Received: from localhost (localhost [127.0.0.1]) by gandalf.osk.com.ua (Postfix) with ESMTP id A22FF78C1F; Fri, 27 Jan 2006 11:38:22 +0200 (EET) Received: from gandalf.osk.com.ua ([127.0.0.1]) by localhost (gandalf.osk.com.ua [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60284-10; Fri, 27 Jan 2006 11:38:22 +0200 (EET) Received: from OLEG (unknown [192.168.82.111]) by gandalf.osk.com.ua (Postfix) with ESMTP id EE0A578C1D; Fri, 27 Jan 2006 11:38:21 +0200 (EET) Date: Fri, 27 Jan 2006 11:36:46 +0200 From: Oleg Tarasov X-Mailer: The Bat! (v3.64.01 Christmas Edition) Professional X-Priority: 3 (Normal) Message-ID: <603364524.20060127113646@osk.com.ua> To: VANHULLEBUS Yvan In-Reply-To: <20060127084457.GA21360@zen.inc> References: <83462512.20060126181018@osk.com.ua> <43D92848.2050005@elischer.org> <20060127084457.GA21360@zen.inc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at osk.com.ua Cc: freebsd-net@freebsd.org Subject: Re: Duplicate SAD entries lead to ESP tunnel malfunction X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: FreeBSD MailList List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 09:36:53 -0000 Hello, VANHULLEBUS Yvan wrote: > net.key.prefered_oldsa, or net.key.preferred_oldsa (changed since > 4.X). > It is 1 by default, and it should be set to 0 to help better > interoperability with lots of peers..... This seems quite like correct solution. I analyzed behavior of the interface and saw upcoming ping requests (obviously) AND outgoing ping echoes, but remote host didn't get them. Obviously incoming packets were decrypted using one of SAs (the new one) but outgoing packets were encrypted using old SA which is not present on remote host due to some problems (like forced reboot, connection problems etc). Normally in this case remote host must report of unknown spi, but rather it lacks this function or it just ignores these packets. As it is a hardware router I am unaware of its behavior. I will test this solution for some time but I am sure this will help. Thanx for really great help - all these troubles are on my production box and every minute of malfunction returns to me with #not good# words of my boss :/ -- Best regards, Oleg Tarasov mailto:subscriber@osk.com.ua