From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 13:45:09 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 EA5F1106564A for ; Wed, 5 Sep 2012 13:45:08 +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 5D5408FC12 for ; Wed, 5 Sep 2012 13:45:05 +0000 (UTC) Received: from ken (ken.zen.inc [192.168.1.4]) by smtp.zeninc.net (smtpd) with ESMTP id 0A6BA2798BC for ; Wed, 5 Sep 2012 15:38:23 +0200 (CEST) Received: by ken (Postfix, from userid 1000) id C767D4040; Wed, 5 Sep 2012 15:38:22 +0200 (CEST) Date: Wed, 5 Sep 2012 15:38:22 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20120905133822.GA4762@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. 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 13:45:09 -0000 On Wed, Sep 05, 2012 at 03:02:20PM +0200, Andreas Longwitz wrote: > Hi, as continuation of 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. 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 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. > At the end a question: At the beginning of ip_ipsec_output() in > ip_ipsec.c the flag PACKET_TAG_IPSEC_PENDING_TDB is used, but I can not > find the place where this flag is set in the kernel. Can somebody > enlighten me ? Good question..... According to my grep and gtags, nowhere...... Yvan.