From owner-freebsd-net@FreeBSD.ORG Sun Oct 23 10:51:57 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 8EAB316A421 for ; Sun, 23 Oct 2005 10:51:57 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from corwin.easynet.fr (smarthost168.mail.easynet.fr [212.180.1.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2780543D46 for ; Sun, 23 Oct 2005 10:51:56 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from easyconnect2121135-233.clients.easynet.fr ([212.11.35.233] helo=smtp.zeninc.net) by corwin.easynet.fr with esmtp (Exim 4.50) id 1ETdSE-0007KA-So for freebsd-net@freebsd.org; Sun, 23 Oct 2005 12:51:55 +0200 Received: from localhost.localdomain (spartacus.zen.inc [192.168.1.20]) by smtp.zeninc.net (smtpd) with ESMTP id 8AB803F17 for ; Sun, 23 Oct 2005 12:51:49 +0200 (CEST) Received: by localhost.localdomain (Postfix, from userid 1000) id 5D39185609; Sun, 23 Oct 2005 12:51:49 +0200 (CEST) Date: Sun, 23 Oct 2005 12:51:49 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20051023105149.GA2532@zeninc.net> References: <435A85F7.3000909@shrew.net> <435AA8BA.6020808@vwsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <435AA8BA.6020808@vwsoft.com> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: IPSec tcp session stalling ( me too ) ... 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: Sun, 23 Oct 2005 10:51:57 -0000 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