From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 18:25:37 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EE5D106567A for ; Fri, 14 Nov 2008 18:25:37 +0000 (UTC) (envelope-from prvs=julian=1973cfe30@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id DFC648FC0C for ; Fri, 14 Nov 2008 18:25:36 +0000 (UTC) (envelope-from prvs=julian=1973cfe30@elischer.org) Received: from jelischer-laptop.sfo.ironport.com (HELO julian-mac.elischer.org) ([10.251.22.38]) by smtp-outbound.ironport.com with ESMTP; 14 Nov 2008 10:25:18 -0800 Message-ID: <491DC28E.80804@elischer.org> Date: Fri, 14 Nov 2008 10:25:18 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: sclark46@earthlink.net References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> <491C2235.4090509@earthlink.net> <1226589468.1976.12.camel@wombat.2hip.net> <491C4EC2.2000802@earthlink.net> <491D6CED.50006@earthlink.net> In-Reply-To: <491D6CED.50006@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, FreeBSD Stable , Robert Noland Subject: Re: FreeBSD 6.3 gre and traceroute 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: Fri, 14 Nov 2008 18:25:37 -0000 Stephen Clark wrote: > Stephen Clark wrote: >>>>> >>>>> 10.0.129.1 FreeBSD workstation >>>>> ^ >>>>> | >>>>> | ethernet >>>>> | >>>>> v >>>>> 10.0.128.1 Freebsd FW "A" >>>>> ^ >>>>> | >>>>> | gre / ipsec >>>>> | >>>>> v >>>>> 192.168.3.1 FreeBSD FW "B" >>>>> ^ >>>>> | >>>>> | ethernet >>>>> | >>>>> v >>>>> 192.168.3.86 linux workstation >>>>> >> Also just using gre's without the >> underlying ipsec tunnels seems to >> work properly. This is the crux of the matter. IPSEC happens INSIDE the IP stack. The IP stack is responsible for the ICMP generation so it is much more likely that there is an interaction there. Now is there an IPSEC rule to make sure that the ICMP packet can get back? It could b ehtat in teh IP stack there is some confusion as to whether the return packet should be encrypted or not and it might get dropped. the code involved is in /sys/netinet and /sys/netipsec but you'll probably regret looking in there ;-) >> >> > Another data point I had been using option FILTER_GIF I tried a kernel > without that option and it behaved the same. > > Steve >