From owner-freebsd-net@FreeBSD.ORG Mon Jan 9 21:53:13 2006 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 83FBC16A41F for ; Mon, 9 Jan 2006 21:53:13 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0209843D45 for ; Mon, 9 Jan 2006 21:53:12 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by smtp2-g19.free.fr (Postfix) with ESMTP id 73F706CC1D; Mon, 9 Jan 2006 22:53:11 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 045119B85B; Mon, 9 Jan 2006 21:53:13 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id BDF08405A; Mon, 9 Jan 2006 22:53:12 +0100 (CET) Date: Mon, 9 Jan 2006 22:53:12 +0100 From: Jeremie Le Hen To: Brian Candler Message-ID: <20060109215312.GV90495@obiwan.tataz.chchile.org> References: <20051228143817.GA6898@uk.tiscali.com> <86lky5p7ik.fsf@srvbsdnanssv.interne.kisoft-services.com> <20051228155545.GA7166@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051228155545.GA7166@uk.tiscali.com> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org Subject: Re: [fbsd] Re: IPSEC documentation 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, 09 Jan 2006 21:53:13 -0000 Hi, Brian, Eric, > I still think that gif + IPSEC tunnel mode (as currently documented) is not > a good approach, especially if it's the *only* mode of operation to be > documented and hence implicitly recommended as the 'right' way to do it. AFAIK, using both gif(4) and IPSec tunnel mode is actually pointless, at least if they use the same outer IP address couple. The routing table is indeed overriden by the IPSec tunnel mode. I tested this in the past and I saw that no packet went through the gif(4) interface. While using tunnel mode, the kernel handles "transparently" a tunnel on which you basically have no further control (impossible to attach a bpf(4) interface, no PFIL_HOOK). I personally find the gif(4)/transport mode setup neater than the single tunnel mode - though I am not aware of initial constrains when IPSec RFCs were written - especially because one can look after the traffic going through the VPN link in a very natural way. Note that it is possible to filter _incoming_ traffic from a VPN running IPSec tunnel mode because the PACKET_TAG_IPSEC_IN_DONE flag is set on the mbuf. You cannot however filter outgoing traffic nor you can know from which tunnel the packet came from when you have multiple tunnels. As Brian pointed out, FreeBSD indeed lacks the enc(4) interface which lives in OpenBSD. enc(4) is a kind of hook into the tunnel mode providing a natural interface to it. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org >