Date: Sun, 23 Oct 2005 12:51:49 +0200 From: VANHULLEBUS Yvan <vanhu_bsd@zeninc.net> To: freebsd-net@freebsd.org Subject: Re: IPSec tcp session stalling ( me too ) ... Message-ID: <20051023105149.GA2532@zeninc.net> In-Reply-To: <435AA8BA.6020808@vwsoft.com> References: <435A85F7.3000909@shrew.net> <435AA8BA.6020808@vwsoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Oct 22, 2005 at 10:01:46PM +0100, Volker wrote: [....] > Is anybody else here with deep TCP + IPSec knowledge able to get a look > into this? Any known issues? Is there anything I might also check out? > Is there a 64k limit with IPSec? :( IPSec works, even for huge datas sessions: I'm using it every day, and a lot of my customers would already have complained about it if there were such problems ! :-) As I said before, this really looks like problems I regulary see, when the ESP packets will have to be fragmented (ESP adds an encapsulation level). Use a lower MTU on your traffic endpoints or play with the TCPMSS value on one gate (at least pf can be configured to do that), and ensure that there is no more fragmented ESP packets between the IPSec gates (of course, TCPMSS solution is easier to set up, but will only work for TCP sessions...). ESP maximum overhead is 4 (SPI) + 4 (seq number) + 255 (padding) + 2 (pad len + next header) + 96 (SHA-1-96 auth value, see RFC 2404) bytes, but usually, overhead will be around 100 bytes (including authentication, but ESP should really not be used without authentication), so setting up for internal hosts an MTU of (Public Interface MTU) - 150 should be enough, without really decreasing global performances. You should also have better performances when this will be fixed. 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?20051023105149.GA2532>