Date: Thu, 29 Dec 2005 13:38:15 +0100 From: VANHULLEBUS Yvan <vanhu_bsd@zeninc.net> To: freebsd-net@freebsd.org Subject: Re: IPSEC documentation Message-ID: <20051229123815.GB1854@zen.inc> In-Reply-To: <20051229122549.GA11055@uk.tiscali.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051229123815.GB1854>