From owner-freebsd-net@FreeBSD.ORG Tue Nov 18 13:13:16 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 D20FF106564A for ; Tue, 18 Nov 2008 13:13:16 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by mx1.freebsd.org (Postfix) with ESMTP id 8E72C8FC1F for ; Tue, 18 Nov 2008 13:13:16 +0000 (UTC) (envelope-from sclark46@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=h5XWmaOHyY7zwwndNn5IjMYPwptDk0tTxlEDlGi5I4kzns1OKOetAQn9Z/TZXAFT; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [208.118.36.229] (helo=joker.seclark.com) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L2QOJ-0006FX-GN; Tue, 18 Nov 2008 08:13:15 -0500 Message-ID: <4922BF6A.1000108@earthlink.net> Date: Tue, 18 Nov 2008 08:13:14 -0500 From: Stephen Clark User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: "Bjoern A. Zeeb" 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> <491DC28E.80804@elischer.org> <1226688153.1719.23.camel@squirrel.corp.cox.com> <20081115102746.K61259@maildrop.int.zabbadoz.net> <4921DBB4.4060505@earthlink.net> <20081118113823.T61259@maildrop.int.zabbadoz.net> In-Reply-To: <20081118113823.T61259@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec799bd063f300eb3963a1bdbc934972a69d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 208.118.36.229 Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 6.3 gre and tracerouteo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2008 13:13:16 -0000 Bjoern A. Zeeb wrote: > On Mon, 17 Nov 2008, Stephen Clark wrote: > > Hi, > >> Bjoern A. Zeeb wrote: >>> On Fri, 14 Nov 2008, Robert Noland wrote: >>> >>> Hi, >>> >>>>>>> Also just using gre's without the >>>>>>> underlying ipsec tunnels seems to >>>>>>> work properly. >>> >>> The reason for this to my knowledge is: >>> http://www.kame.net/dev/cvsweb2.cgi/kame/freebsd2/sys/netinet/ip_icmp.c#rev1.4 >>> >>> or looking at recent freebsd code: >>> http://fxr.watson.org/fxr/source/netinet/ip_icmp.c#L164 >>> Look for M_DECRYPTED. >>> >>> Now what happens in your case: >>> >>> you receive an IPSec ESP packet, which gets decryped, that sets >>> M_DECRYPTED on the mbuf passes through various parts, gets up to gre, >>> gets decapsulated is an IP packet (again) gets to ip_input, TTL >>> expired, icmp_error and it's still the same mbuf that originally got >>> the M_DECRYPTED set. Thus the packets is just freed and you never see >>> anything. >>> >>> So thinking about this has nothing to do with gre (or gif for example >>> as well) in first place. It's arguably that passing it on to another >>> decapsulation the flag should be cleared when entering gre() for >>> example. >>> >>> The other question of course is why we do not send the icmp error back >>> even on plain ipsec? Is it because we could possibly leak information >>> as it's not caught by the policy sending it back? >>> >>> /bz >>> >> Update: >> >> Adding this code in ip_icmp.c makes the traceroute work. >> case IPPROTO_GRE: >> hlen += sizeof(struct gre_h); >> >> + m->m_flags &= ~(M_DECRYPTED); > > I have two problems with this: > > 1) my ip_icmp.c doesn't know anything about GRE (in HEAD or on my 6.x > box) unless I need more coffee. > > 2) This obviously doesn't solve the problem for gif(4), ... > > > Can you tell me which brnach you are working against (I guess it's > 6.3?) and generate a proper diff? > > > /bz > Duh sorry - should have said ip_gre.c and it is 6.3-p5 *** ip_gre.c.ori Tue Nov 18 08:09:16 2008 --- ip_gre.c Tue Nov 18 08:10:27 2008 *************** *** 153,158 **** --- 153,161 ---- switch (proto) { case IPPROTO_GRE: hlen += sizeof(struct gre_h); + + m->m_flags &= ~(M_DECRYPTED); + /* process GRE flags as packet can be of variable len */ flags = ntohs(gip->gi_flags); Your right about gif(4) - probably something similar is needed. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson)