From owner-freebsd-net@FreeBSD.ORG Mon Oct 24 22:23:58 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 CF8F816A41F for ; Mon, 24 Oct 2005 22:23:58 +0000 (GMT) (envelope-from volker@vwsoft.com) Received: from tce71.tce85.de (tce71.tce85.de [195.145.102.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55D0543D45 for ; Mon, 24 Oct 2005 22:23:58 +0000 (GMT) (envelope-from volker@vwsoft.com) Received-SPF: unknown (tce71.tce85.de: error in processing during lookup of domain of vwsoft.com: Could not find a valid SPF record) client-ip=83.242.61.87; envelope-from=volker@vwsoft.com; helo=mail.vtec.ipme.de; Received: from mail.vtec.ipme.de (87-61-242-83.dip.h-tel.de [83.242.61.87]) by tce71.tce85.de (Postfix) with ESMTP id A1F4417092 for ; Tue, 25 Oct 2005 00:23:51 +0200 (CEST) Received: from [192.168.16.3] (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id 0B2D85C4E for ; Tue, 25 Oct 2005 00:07:43 +0200 (CEST) Message-ID: <435D693F.5090502@vwsoft.com> Date: Tue, 25 Oct 2005 00:07:43 +0100 From: Volker User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Thunderbird/1.0.6 Mnenhy/0.6.0.101 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.92.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-TarmacCE-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com Subject: more on IPSec + gif stalling 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: Mon, 24 Oct 2005 22:23:58 -0000 Hi guys! I've done another test on the IPSec + gif issue. Here at my home network I'm running a RELENG_6 box and I've also just setup a 2nd test server (RELEASE_5_4). Both are connected by a direct 100 MBit/s LAN connection. Set up IPSec rules for both machines, created a gif tunnel between both and send traffic through the tunnel and the result is the same. As soon as some amount of data (somewhat around 56k to 64k) has been transferred through the gif tunnel, the transfer session stalls. When not using a gif tunnel over IPSec, everything is fine. This means: IPSec + gif + firewall (pf) = tcp sessions within the gif tunnel stalls IPSec + gif - firewall = just works IPSec - gif + firewall = just works -IPSec + gif + firewall = just works In my test scenario I've secured the outside of the gif tunnel by IPSec. I haven't checked what happens when the inside of the gif tunnel is being secured by IPSec. Also I've checked with both kernel options IPSEC and FAST_IPSEC. It didn't make a difference. I've checked the inside of the gif tunnel and the outside for suspicious packets but couldn't find one. I've checked for IPSec tunnel mode and transport mode and as soon as I'm using a gif tunnel, a data session running inside the gif tunnel dies sooner or later (transport/tunnel does not make any difference to this issue). When disabling the firewall (pf) at the __senders' side__ (important!) the data transfer does not stall. Nothing is being blocked by the firewall (tripple checked). It's not just pf as ipfw is being reported to the same effect. pf 'scrub' rules doesn't make any difference (tested with and without scrubbing). Really, I don't believe this is an MTU issue. In my test scenario I've two hosts directly connected via ethernet (100BaseT), MTU = 1500, gif MTU = 1280, no router between. If somebody else is using a gif tunnel over IPSec on a recent release (RELENG_5/6, RELEASE_5_x) plus firewall, please provide me (by private email) with your kernel config, racoon.conf and your ipsec rules. That way I might check out different kernel settings and test that out here using my test setup. When talking about 'tcp session within the gif tunnel': I haven't checked if this also happens to udp. I've checked tcp sessions through the gif tunnel by scp and a plain ascii transfer by using (g)netcat. Matthew and me have dealt out to test an IPSec + gif setup over the public internet one more time. I bet this will show the stalling, too. bye, Volker