Skip site navigation (1)Skip section navigation (2)
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>