From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 12:38:22 2005 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 972D616A41F for ; Thu, 29 Dec 2005 12:38:22 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from caine.easynet.fr (smarthost167.mail.easynet.fr [212.180.1.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D3F643D86 for ; Thu, 29 Dec 2005 12:38:17 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from easyconnect2121135-233.clients.easynet.fr ([212.11.35.233] helo=smtp.zeninc.net) by caine.easynet.fr with esmtp (Exim 4.50) id 1Erx2u-0000xP-Hv for freebsd-net@freebsd.org; Thu, 29 Dec 2005 13:38:16 +0100 Received: by smtp.zeninc.net (smtpd, from userid 1000) id 216653F17; Thu, 29 Dec 2005 13:38:15 +0100 (CET) Date: Thu, 29 Dec 2005 13:38:15 +0100 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20051229123815.GB1854@zen.inc> References: <20051228143817.GA6898@uk.tiscali.com> <001401c60bc0$a3c87e90$1200a8c0@gsicomp.on.ca> <20051228153106.GA7041@uk.tiscali.com> <20051228164339.GB3875@zen.inc> <43B38747.1060906@iteranet.com> <20051229122549.GA11055@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051229122549.GA11055@uk.tiscali.com> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: IPSEC documentation 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: Thu, 29 Dec 2005 12:38:22 -0000 On Thu, Dec 29, 2005 at 12:25:49PM +0000, Brian Candler wrote: > On Thu, Dec 29, 2005 at 09:50:47AM +0300, Alexey Popov wrote: > > If we would also have NAT-T support, FreeBSD would be the best choice > > of VPN concentrator. > > /usr/ports/security/ipsec-tools/pkg-descr says: > > "Known issues: > - Non-threaded implementation. Simultaneous key negotiation performance > should be improved." > > I think that would limit its usefulness as a scalable concentrator, if the > comment is still valid. The comment is still valid, but impact is not so strong. Key negociations doesn't happen so much during an IPSec tunnel lifetime, and negociating simultaneous SAs will be slow even with a multi-threaded implementation if you have a low-end CPU. And if you have a high-end CPU, SAs will be negociated quickly, then the impact of negociating simultaneous SAs will be limited. Yvan. -- NETASQ - Secure Internet Connectivity http://www.netasq.com