Date: Mon, 9 Jan 2006 23:15:35 +0100 From: Jeremie Le Hen <jeremie@le-hen.org> To: Phil Regnauld <regnauld@catpipe.net> Cc: freebsd-net@freebsd.org, misc@openbsd.org, Jeremie Le Hen <jeremie@le-hen.org>, Brian Candler <B.Candler@pobox.com> Subject: Re: [fbsd] Re: [fbsd] Re: IPSEC documentation Message-ID: <20060109221535.GW90495@obiwan.tataz.chchile.org> In-Reply-To: <20060109220142.GD17334@flow.eu.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060109221535.GW90495>