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