From owner-freebsd-net Mon Apr 8 14:40:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 3C77137B417 for ; Mon, 8 Apr 2002 14:40:08 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020408214007.CKCE21252.rwcrmhc53.attbi.com@InterJet.elischer.org>; Mon, 8 Apr 2002 21:40:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA53026; Mon, 8 Apr 2002 14:30:14 -0700 (PDT) Date: Mon, 8 Apr 2002 14:30:13 -0700 (PDT) From: Julian Elischer To: Lars Eggert Cc: "Rogier R. Mulhuijzen" , mgt@hytekblue.com, freebsd-net@FreeBSD.ORG Subject: Re: IPsec tunnel mode In-Reply-To: <3CB2098C.5080904@isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org you can do another form of tunnelling by using a netgraph interface. Assign the required address to the netgraph interface and then use the IP-over-UDP example in the netgraph examples. tehn set up teh security associations so that the UDP packets generated are encrypted.. this is basically the same as doing a gif interface, except using UDP as the carrier. Be careful about creating loops however If I had copious free time I think IPSEC could be hacked to interract with netgraph to give the kind of interaction you are talkign about however. On Mon, 8 Apr 2002, Lars Eggert wrote: > Rogier R. Mulhuijzen wrote: > >> http://www.x-itec.de/projects/tuts/ipsec-howto.txt > > > > Unfortunately this howto, like any other mention of IPsec & > > tunneling on the net uses the gif interface. Which is IPoverIP, and > > this does not seem to match with IPsec tunnel devices. > > There are no IPsec tunnel devices in KAME. IPsec defines "security > associations" (SAs), which are not represented as devices in the routing > table in KAME. Thus, you can't use routes to direct traffic into these > tunnel mode SAs, you need to set up your security policies with the > correct selectors (think firewall-like matching). > > *Many* tutorials on the net do not understand this disctinction, and > tell you to set up an IPIP tunnel (using a gif) and an IPsec tunnel > mode SA in parallel. This is a bad hack, since you (ab)use a side effect > of creating an IPIP tunnel device (it can be used for route entries) to > redirect traffic into your (separate) tunnel mode SA. Very roughly, you > set up the IPIP tunnel, then yank out the packets destined for it during > outbound processing and force them over an IPsec tunnel mode SA. > > Use EITHER IPsec tunnel mode alone OR IPIP tunnels and IP transport > mode (draft-touch-ipsec-vpn). Mixing both can work in some scenarios > where the dependencies between side effects are just right, but in > general, it's a broken approach. > > Lars > -- > Lars Eggert Information Sciences Institute > http://www.isi.edu/larse/ University of Southern California > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message