From owner-freebsd-net Fri Jan 3 2: 5:27 2003 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 5593737B401 for ; Fri, 3 Jan 2003 02:05:25 -0800 (PST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2EA043EC2 for ; Fri, 3 Jan 2003 02:05:24 -0800 (PST) (envelope-from pekka.nikander@nomadiclab.com) Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id BE37423; Fri, 3 Jan 2003 12:13:49 +0200 (EET) Message-ID: <3E15604B.3040505@nomadiclab.com> Date: Fri, 03 Jan 2003 12:04:59 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3b) Gecko/20021230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Masson Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPsec / ipfw interaction in 4.7-STABLE: a proposed change References: <3E144753.7020905@nomadiclab.com> <86k7hnz4hp.fsf@notbsdems.nantes.kisoft-services.com> In-Reply-To: <86k7hnz4hp.fsf@notbsdems.nantes.kisoft-services.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 Eric Masson wrote: > Seems pretty close to what OpenBSD has implemented, except they don't > use the stock loopback interface. > > Their enc(4) driver is a software loopback interface : > http://www.openbsd.org/cgi-bin/man.cgi?query=enc&sektion=4&arch=i386&apropos=0&manpath=OpenBSD+Current Thanks for the pointer! > It's used in src/sys/netinet/ipsec_input.c to impersonate the incoming > interface just as you did in your patch. > > I'd like to know whether there would be any interest in associating a > different interface to each incoming SPD entry or just use only one > interface for all incoming SPD entries ? Well, IMHO the best way would be to have a separate interface for each tunnel end point. That would allow most fine grained control, and would be easiest to understand. Perhaps something like the following: ifconfig enc0 up ifconfig enc0 192.168.0.129 netmask 255.255.255.0 ifconfig xl1 192.168.0.130 netmask 255.255.255.128 setkey -c << EOF spdadd 192.168.0.0/24 192.168.0.128/25 any -P in ipsec esp/tunnel/XXX-YYY/require; spdadd 192.168.0.128/25 192.168.0.0/24 any -P out ipsec ESP/tunnel/YYY-XXX/require; EOF Even better would be if you could use just on IP address instead of having a separate address at the tunnel interface and another one at the internal network interface, but I'm not sure if that would work. When IPsec is not used or properly configured, the enc interface could be just a black hole, discarding any packets that are not processed and tunneled by IPsec. With the received packets, the IPsec code would need to go through the configured enc interfaces, and find one where the source address would match... Now, all this has one not-so-good design aspect: in a way you need to configure the tunnel twice: once the enc interface, IP addresses and routing etc, and a second time set up the proper IPsec SPD entries. Perhaps the enc interface could be even more intelligent, and set up default SPD entries based on routing tables??? --Pekka Nikander To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message