From owner-freebsd-net@FreeBSD.ORG  Wed Sep 12 12:19:35 2012
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 9C57D106566C
	for <freebsd-net@freebsd.org>; Wed, 12 Sep 2012 12:19:35 +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 4FBBD8FC12
	for <freebsd-net@freebsd.org>; Wed, 12 Sep 2012 12:19:34 +0000 (UTC)
Received: from ken (ken.zen.inc [192.168.1.4])
	by smtp.zeninc.net (smtpd) with ESMTP id D2CD92798BC;
	Wed, 12 Sep 2012 14:19:27 +0200 (CEST)
Received: by ken (Postfix, from userid 1000)
	id A92D34040; Wed, 12 Sep 2012 14:19:27 +0200 (CEST)
Date: Wed, 12 Sep 2012 14:19:27 +0200
From: VANHULLEBUS Yvan <vanhu@FreeBSD.org>
To: Andreas Longwitz <longwitz@incore.de>
Message-ID: <20120912121927.GA3968@zeninc.net>
References: <50474D5C.4020003@incore.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <50474D5C.4020003@incore.de>
User-Agent: All mail clients suck. This one just sucks less.
Cc: freebsd-net@freebsd.org
Subject: Re: Support for IPSec VPN's: some patches for netipsec/key.c
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Sep 2012 12:19:35 -0000

Hi.

On Wed, Sep 05, 2012 at 03:02:20PM +0200, Andreas Longwitz wrote:
[...]
> The last patch makes it possible for a transport mode client to open a
> new connection to the server immediately after closing an old
> connection. Without this patch the client must wait for the routers to
> forget all there NAT entries.
> 
> @@ -4065,10 +4084,12 @@
>           /*
>            * If NAT-T is enabled, check ports for tunnel mode.
>            * Do not check ports if they are set to zero in the SPD.
> -          * Also do not do it for transport mode, as there is no
> +          * Also do not do it for native transport mode, as there is no
>            * port information available in the SP.
>            */
> -         if (saidx1->mode == IPSEC_MODE_TUNNEL &&
> +         if ((saidx1->mode == IPSEC_MODE_TUNNEL ||
> +             (saidx1->mode == IPSEC_MODE_TRANSPORT &&
> +             saidx1->proto == IPPROTO_ESP)) &&
>               saidx1->src.sa.sa_family == AF_INET &&
>               saidx1->dst.sa.sa_family == AF_INET &&
>               ((const struct sockaddr_in *)(&saidx1->src))->sin_port &&

Sorry for the delay, I just commited it on HEAD.


Thanks for the patch, I'll try to take time to have a look at your
other patches/issues ASAP, feel free to send updated versions, mail
me, etc....


Yvan.