From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 15:47:23 2012 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 A2E731065680; Wed, 5 Sep 2012 15:47:23 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 30A278FC12; Wed, 5 Sep 2012 15:47:23 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 125B05C692; Wed, 5 Sep 2012 17:47:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id tErjlFqUw_8g; Wed, 5 Sep 2012 17:47:21 +0200 (CEST) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 1CADB5C691; Wed, 5 Sep 2012 17:47:21 +0200 (CEST) Received: from bsdlo.incore (bsdlo.incore [192.168.0.84]) by mail.incore (Postfix) with ESMTP id 14B0645087; Wed, 5 Sep 2012 17:47:21 +0200 (CEST) Message-ID: <50477408.30003@incore.de> Date: Wed, 05 Sep 2012 17:47:20 +0200 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: VANHULLEBUS Yvan , freebsd-net@freebsd.org References: <50474D5C.4020003@incore.de> <20120905133822.GA4762@zeninc.net> In-Reply-To: <20120905133822.GA4762@zeninc.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 15:47:23 -0000 Hi, >> The following patches are all for netipsec/key.c: >> >> I use parameter "generate_policy on" in racoon.conf. This works for >> clients with NAT-T, but direct connected clients need the following >> patch (likewise in ipsec-tools/roadwarrior/client/phase1-up.sh): >> >> @@ -1927,19 +1930,27 @@ >> #if 1 >> if (newsp->req && newsp->req->saidx.src.sa.sa_family) { >> struct sockaddr *sa; >> + uint16_t *pport; >> sa = (struct sockaddr *)(src0 + 1); >> if (sa->sa_family != newsp->req->saidx.src.sa.sa_family) { >> _key_delsp(newsp); >> return key_senderror(so, m, EINVAL); >> } >> + pport = (uint16_t *)newsp->req->saidx.src.sa.sa_data; >> + if ( *pport == htons(500) ) /* UDP_ENCAP_ESPINUDP_PORT */ >> + *pport = 0; >> } >> if (newsp->req && newsp->req->saidx.dst.sa.sa_family) { >> struct sockaddr *sa; >> + uint16_t *pport; >> sa = (struct sockaddr *)(dst0 + 1); >> if (sa->sa_family != newsp->req->saidx.dst.sa.sa_family) { >> _key_delsp(newsp); >> return key_senderror(so, m, EINVAL); >> } >> + pport = (uint16_t *)newsp->req->saidx.dst.sa.sa_data; >> + if ( *pport == htons(500) ) /* UDP_ENCAP_ESPINUDP_PORT */ >> + *pport = 0; >> } >> #endif > > I'm not sure it will happen in real life configurations, but if > someones does really want to setup a SP entry for port 500 (tunnel > mode, or anything else which may need that), your patch will prevent > it from working. Yes, I agree. > It may be cleaner to have racoon generate the good SP entry, rather > than kernel trying to guess what is right in a SPDADD command. The SPDADD command is done by racoon because I have generate_policy on, but racoon sets ports to 500 for direct connected clients. If this would be fixed in racoon, then the above kernel patch is superfluous. >> 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 && > > Right, I'll commit it on HEAD ASAP. Good news, thanks ! Andreas Longwitz