From owner-freebsd-net@FreeBSD.ORG Thu Jun 26 08:12:27 2008 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 0C9CB1065679 for ; Thu, 26 Jun 2008 08:12:27 +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 B8F878FC13 for ; Thu, 26 Jun 2008 08:12:26 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id 7D3DF3F7A; Thu, 26 Jun 2008 09:53:07 +0200 (CEST) Date: Thu, 26 Jun 2008 09:53:07 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20080626075307.GA1401@zen.inc> References: <48629DE0.5000407@elischer.org> <7ec5b81263bb9dc933d392a8efb26136@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7ec5b81263bb9dc933d392a8efb26136@localhost> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: FreeBSD NAT-T patch integration 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: Thu, 26 Jun 2008 08:12:27 -0000 On Wed, Jun 25, 2008 at 07:13:59PM -0500, mgrooms wrote: [...] > To my knowledge, here are the latest patch sets ... > > http://vanhu.free.fr/FreeBSD/patch-natt-freebsd6-2007-05-31.diff > http://vanhu.free.fr/FreeBSD/patch-natt-freebsd7-2008-03-11.diff > http://vanhu.free.fr/FreeBSD/patch-natt-freebsd-HEAD-2008-03-19.diff Yes: latest version of the patch will always be the file at that location with the most recent date. I have copies of repositories for HEAD, RELENG7 and RELENG6, and I can generate more up-to date patches if needed. I use patch for freebsd6 and freebsd7 in daily production, and can quite quickly test new versions if needed. I do NOT use directly the patch for HEAD actually, but should have a testing device for that soon. If some people have their own changes for those patches, please send them to me !!! What still lacks afaik in that patch: - support for NAT-OA. This is needed for transport mode when traffic is TCP (and when UDP traffic have a non zero checksum), such support needs some stuff in decapsulation process, complete support for NAT-OA payloads in PFKey, and complete support in userland. - Cleanup of PFKeyV2. Actually, NAT-T ports are not sent in a RFC compliant way (but it works). That cleanup needs also to be done in userland, and is on my TODO list (both kernel and userland). - Better detection of NAT-T support. Actually, ipsec-tools guess kernel support for NAT-T by checking some stuff in /usr/include. That just means you appliend the NAT-T patch, but that doesn't means you enabled NAT-T support in your kernel. Same problem exists for other implementations (at least Linux 2.6+ and NetBSD), a cleaner detection should also do "some checks" at runtime to ensure actual kernel really supports NAT-T. But that's an userland problem, and you can easilly force ipsec-tools compilation WITHOUT NAT-T support. Yvan. -- NETASQ http://www.netasq.com