From owner-freebsd-net@FreeBSD.ORG Fri Sep 17 14:07:20 2010 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 784DA1065670 for ; Fri, 17 Sep 2010 14:07:20 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from eu1sys200aog110.obsmtp.com (eu1sys200aog110.obsmtp.com [207.126.144.129]) by mx1.freebsd.org (Postfix) with SMTP id 0B1D08FC14 for ; Fri, 17 Sep 2010 14:07:18 +0000 (UTC) Received: from source ([63.174.175.251]) by eu1sys200aob110.postini.com ([207.126.147.11]) with SMTP ID DSNKTJN2FdFhoT9LsC+Ar7NwXyl/4Crz2vAP@postini.com; Fri, 17 Sep 2010 14:07:19 UTC Received: from [172.17.10.53] (unknown [172.17.10.53]) by bbbx3.usdmm.com (Postfix) with ESMTP id 7E555FD01A; Fri, 17 Sep 2010 14:07:17 +0000 (UTC) Message-ID: <4C93760B.8050206@tomjudge.com> Date: Fri, 17 Sep 2010 09:07:07 -0500 From: Tom Judge User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100826 Lightning/1.0b1 Thunderbird/3.0.7 MIME-Version: 1.0 To: Vladimir Grigorov References: <4C923353.7090801@tomjudge.com> <1307024327.20100917121857@gmail.com> In-Reply-To: <1307024327.20100917121857@gmail.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Fwd: Re: Strange FreeBSD behavior when trying to forward beetween ipsec crypted gif's. May be a problem with ICMP unreach packets at all 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, 17 Sep 2010 14:07:20 -0000 On 09/17/2010 03:18 AM, Vladimir Grigorov wrote: > greets all > > > >> If you take a look at icmp_error() in sys/netinet/ip_icmp.c you will see >> that icmp errors are not sent for packets that have been previously been >> decrypted by IPSec. >> > May be some misunderstandings happens. I have gif and ipsec. IPSEC mode is transport, that means, traffic encrypted only between gif's > outer addresses. As result, traffic in gif encrypted by encrypting ipip container. But I can view traffic on gif by tcpdump as on > regular interfaces. E.g. gif's inner traffic not processed by ipsec at all > > Consider you have a packet that looks something like this: |IP[1]|ESP|IP[2]|IP[3]|| 1) The packet enters ip_input() is validated against a policy and that its IP[1] header lists the router as the destination. 2) ip_input() passes the frame (mbuf) into ip_ipsec_input() which will return 0 and allow the frame to continue to be processed. 3) ip_input() then (eventually) calls esp_input() which in turn calls esp_input_cb() 4) esp_input_cb() does the decryption work and tags the mbuf containing the frame with M_DECRYPTED at this stage the frame in the mbuf will look like this: |IP[2]|IP[3]|| 5) esp_input_cp() passes the processed mbuf to ipsec_common_input_cb() which will redispatch the mbuf (frame) to in_gif_input() via the netisr queue. 6) in_gif_input() calls gif_input() to process the frame which will look like this: |IP[3]|| *Note: the mbuf this frame is stored in is the same mbuf as the original packet was received in by the NIC so still carries the flag M_DECRYPTED. 7) gif_input() re dispatches the mbuf via the netisr queue again. 8) Packet causes a call to icmp_error() in either ip_input() or ip_foarward() and ecmp_error() does not send the message as M_DECRYPTED is set. I have missed/glossed over a few steps here I feel, but in general I think from my 15 minutes reading the code this is how it works (or at least the important parts of it). Hope this helps. Tom -- TJU13-ARIN