From owner-freebsd-net@FreeBSD.ORG Mon Oct 19 20:05:52 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA030106566B for ; Mon, 19 Oct 2009 20:05:52 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 92CC28FC0A for ; Mon, 19 Oct 2009 20:05:52 +0000 (UTC) Received: from ken.zen.inc (ken.zen.inc [192.168.1.4]) by smtp.zeninc.net (smtpd) with ESMTP id BAB952798BC; Mon, 19 Oct 2009 22:05:50 +0200 (CEST) Received: by ken.zen.inc (Postfix, from userid 1000) id 063B3B9A93; Mon, 19 Oct 2009 22:05:49 +0200 (CEST) Date: Mon, 19 Oct 2009 22:05:49 +0200 From: vanhu To: Eric Masson Message-ID: <20091019200549.GA9766@zeninc.net> References: <861vkzlula.fsf@srvbsdnanssv.interne.kisoft-services.com> <9a542da30910190707q7eb173d9xf9085d220a213db1@mail.gmail.com> <86eiozjt6p.fsf@srvbsdnanssv.interne.kisoft-services.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86eiozjt6p.fsf@srvbsdnanssv.interne.kisoft-services.com> User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-net@freebsd.org Subject: Re: IPSec, nat on enc device 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, 19 Oct 2009 20:05:52 -0000 Hi all. On Mon, Oct 19, 2009 at 05:32:14PM +0200, Eric Masson wrote: [....] > I know ;) I'll bug them regarding ${suject} as well (some ipsec-tools > devs lurk there too) Do you think so ? :-D > I'm not sure that pf & ipsec stack already support this feature. Maybe > bz@ or vanhu@ will shed a light on this point. This is a way to do that, but it needs some stuff on both kernel and userland to be implemented that way. Another way to have this feature is to implement what we call "NAT before VPN": you can configure your kernel (or do it for specific NAT rules if you want to do a more flexible implementation) to do NAT process before doing IPsec stuff. Then, you just write your NAT rules to move local/remote traffic endpoints to distinct networks, and IPsec (both in kernel and userland) will just have to deal with those NATed networks. OpenBSD's way of doing things seems interesting while reading very quickly your link, I'll have to take some more time to really see exactly what they are doing..... Yvan.