From owner-freebsd-net@freebsd.org Sun Dec 11 11:58:14 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D4BDBC726D8 for ; Sun, 11 Dec 2016 11:58:14 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 989D4189C; Sun, 11 Dec 2016 11:58:14 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cG2lW-0003Ix-Lt; Sun, 11 Dec 2016 14:58:02 +0300 Date: Sun, 11 Dec 2016 14:58:02 +0300 From: Slawa Olhovchenkov To: "Andrey V. Elsukov" Cc: Eugene Grosbein , freebsd-net@FreeBSD.org Subject: Re: [RFC/RFT] projects/ipsec Message-ID: <20161211115802.GD31311@zxy.spb.ru> References: <2bd32791-944f-2417-41e9-e0fe1c705502@FreeBSD.org> <584D18D1.8090400@grosbein.net> <36fa749c-f284-1d96-704c-b7118a574dd0@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <36fa749c-f284-1d96-704c-b7118a574dd0@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 11 Dec 2016 11:58:14 -0000 On Sun, Dec 11, 2016 at 02:33:43PM +0300, Andrey V. Elsukov wrote: > On 11.12.2016 12:13, Eugene Grosbein wrote: > > 11.12.2016 6:07, Andrey V. Elsukov пишет: > > > >> * use transport mode IPsec for forwarded IPv4 packets now unsupported. > >> This matches the IPv6 behavior, and since we can handle the replies, I > >> think it is useless. > > > > Does it include a case of packets going from LAN and forwarded into > > gif(4) tunnel > > connected to remote IPSEC gateway and encrypted with transport mode? > > > > That is, will this configuration break? > > No. An encapsulated by gif(4) packet is considered as own packet. The > described change is related to transport mode policies, that are match > forwarded packets, i.e. when source and destination addresses are not > our own. In this case we can't handle the returned packets. What difference with source packets? Whu you can handle sourced and can't handle returned packets?