From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 23 05:24:12 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF8E216A4CE for ; Tue, 23 Mar 2004 05:24:12 -0800 (PST) Received: from bastix.tunix.nl (bastix.tunix.nl [193.79.201.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6110B43D31 for ; Tue, 23 Mar 2004 05:24:11 -0800 (PST) (envelope-from rene@tunix.nl) Received: (from root@localhost) by bastix.tunix.nl (8.9.3c/8.6.12) id OAA20247; Tue, 23 Mar 2004 14:25:30 +0100 (CET) Received: by bastix.tunix.nl (TUNIX txp2/smap) id sma019651; Tue, 23 Mar 04 14:24:17 +0100 Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <49BB582A-7CCD-11D8-96C2-00039357FA7A@tunix.nl> Content-Transfer-Encoding: quoted-printable From: Rene de Vries Date: Tue, 23 Mar 2004 14:23:35 +0100 To: Sam Leffler X-Mailer: Apple Mail (2.613) X-Mailman-Approved-At: Tue, 23 Mar 2004 05:57:42 -0800 cc: hackers@freebsd.org Subject: Fast IPSEC and hardware acceleration X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2004 13:24:12 -0000 Sam, I've been testing with FAST_IPSEC w/ hifn/ubsec cards and I found=20 something which I think is a bug. Maybe you can shine some light on=20 this issue? Configuration: - D 4.7-RELEASE w/ IPSEC - O 4.8-RELEASE w/ FAST_IPSEC + hifn (Soekris 1401) - G 4.9-STABLE w/ FAST_IPSEC + ubsec (Broadcom SSL800) (The 4.8 system could not be upgraded, therefor only the hifn driver=20 was ported back from 4.9-RELEASE.) The IPsec setup uses racoon and has SPDs for transport esp between each=20= system (3des and sha1 are used as cipher and authentication). Connections from D to O work with net.inet.ipsec.crypto_support=3D0 (or=20= -1/1). Connections from D to G don't work with net.inet.ipsec.crypto_support=3D0=20= (or 1). Connections from O to G don't work with net.inet.ipsec.crypto_support=3D0=20= (or 1). Connections from D to G work with net.inet.ipsec.crypto_support=3D-1 Connections from O to G work with net.inet.ipsec.crypto_support=3D-1 So I concluded that the hardware encryption failed for 3des on ubsec... Now for the weird part, if I use manual keys "TESTTESTTESTTESTTESTTEST"=20= everything seems to work just fine. Please contact me if more information is needed. Rene --=20 Ren=E9 de Vries Tunix Internet Security & Training=