From owner-freebsd-net@FreeBSD.ORG Tue Jul 22 00:03:24 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 C58C41065676; Tue, 22 Jul 2008 00:03:24 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from shrew.net (shrew.net [206.223.169.85]) by mx1.freebsd.org (Postfix) with ESMTP id 92A3F8FC15; Tue, 22 Jul 2008 00:03:24 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from localhost (wm-ca.hub.org [206.223.169.82]) by shrew.net (Postfix) with ESMTP id 7987B79E30E; Mon, 21 Jul 2008 19:03:24 -0500 (CDT) Received: from shrew.net ([206.223.169.85]) by localhost (mx1.hub.org [206.223.169.82]) (amavisd-new, port 10024) with ESMTP id 87696-08; Tue, 22 Jul 2008 00:03:23 +0000 (UTC) Received: from hole.shrew.net (cpe-70-113-206-103.austin.res.rr.com [70.113.206.103]) by shrew.net (Postfix) with ESMTP id 7D50779E307; Mon, 21 Jul 2008 19:03:23 -0500 (CDT) Received: from [10.22.200.30] ([10.22.200.30]) by hole.shrew.net (8.14.2/8.14.2) with ESMTP id m6M03LT8072777; Mon, 21 Jul 2008 19:03:21 -0500 (CDT) (envelope-from mgrooms@shrew.net) Message-ID: <488523D0.30300@shrew.net> Date: Mon, 21 Jul 2008 19:03:28 -0500 From: Matthew Grooms User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: vanhu@freebsd.org References: <488515FF.2020309@shrew.net> <48851B00.1060600@shrew.net> In-Reply-To: <48851B00.1060600@shrew.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD NAT-T patch integration [CFR/CFT] 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: Tue, 22 Jul 2008 00:03:24 -0000 > > I noticed this too. But the only situation that I could think of where a > > valid ISAKMP packet will be smaller than this is a NAT-T keep-alive. > > These are handled previously in the code path so I don't think there is > > an issue from a functional standpoint. > > That's what I also supposed when I noticed that, but I was tracking > down a negotiation problem (as an initiator, responder's first > exchange in Main mode was seen on tcpdump but not on racoon's log), > and it has been solved by fixing that part of the code.... > Sounds reasonable. > > On a related note, I noticed the patch unconditionally uses a source > > port of 500 when processing outbound Draft 00/01 packets. Should this > > value be obtained from the SAD NAT-T mapping to support an IKE daemon > > bound to a non standard port? > > It should really really not happen..... but yes, it would be cleaner > to get it from SAD than setting 500 anytime. > Well, its really really supported by all the IKE daemons I have seen in the ports collection. Someone is bound to try this and then spend a lot of time scratching their head. If this situation can be easily avoided, it should be. -Matthew