From owner-freebsd-net@FreeBSD.ORG Mon Jan 9 22:15:38 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 8F36A16A41F for ; Mon, 9 Jan 2006 22:15:38 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD0C143D48 for ; Mon, 9 Jan 2006 22:15:35 +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 smtp1-g19.free.fr (Postfix) with ESMTP id 48A4C6E51B; Mon, 9 Jan 2006 23:15:33 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id C41A59B85B; Mon, 9 Jan 2006 22:15:35 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id A4E76405A; Mon, 9 Jan 2006 23:15:35 +0100 (CET) Date: Mon, 9 Jan 2006 23:15:35 +0100 From: Jeremie Le Hen To: Phil Regnauld Message-ID: <20060109221535.GW90495@obiwan.tataz.chchile.org> References: <20051228143817.GA6898@uk.tiscali.com> <86lky5p7ik.fsf@srvbsdnanssv.interne.kisoft-services.com> <20051228155545.GA7166@uk.tiscali.com> <20060109215312.GV90495@obiwan.tataz.chchile.org> <20060109220142.GD17334@flow.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060109220142.GD17334@flow.eu.org> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, misc@openbsd.org, Jeremie Le Hen , Brian Candler Subject: Re: [fbsd] 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 22:15:38 -0000 Hi Phil, > > 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. I forgot to add that though both setup basically achieve the same purpose, they are not compatible and one have to use IPSec tunnel mode in order to get non-BSD systems work. > > 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. > > Linux (FreeS/WAN) has a similar concept with the ipsec interface > type. IMHO, both modes are useful. On a very large VPN concentrator > with many tunnels being created and destroyed all the time, and > possible several hundred connections at any given time, the interface > table become big. Usually with so many tunnels, typical for roaming > clients, I'll filter on the source IP (the remote end) at the > moment of leaving the interface. Yes indeed, you are right. I dare to Cc: misc@openbsd.org in order to get an answer about performances when there are a huge number of IPSec tunnels. > One could argue that the gif/transport is cleaner in that it doesn't > invent yet another interface type, but racoon/ipsec-tools isn't aware > of it. The ideal would be to have the possibility of dynamically > creating tun(4) devices representing the tunnel endpoints, if required, > when phase2 has been established. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org >