From owner-freebsd-security Fri Aug 2 10:43:28 2002 Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 512C437B400 for ; Fri, 2 Aug 2002 10:43:23 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id A29AD43E75 for ; Fri, 2 Aug 2002 10:43:22 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020802174322.HKUX22139.rwcrmhc52.attbi.com@blossom.cjclark.org>; Fri, 2 Aug 2002 17:43:22 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g72HhMJK007147; Fri, 2 Aug 2002 10:43:22 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g72HhMlu007146; Fri, 2 Aug 2002 10:43:22 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Fri, 2 Aug 2002 10:43:21 -0700 From: "Crist J. Clark" To: Matthew Grooms Cc: freebsd-security@FreeBSD.org Subject: Re: esp tunnel without gif(4) [Was Re: vpn1/fw1 NG to ipsec/racoontroubles, help please ...] Message-ID: <20020802174321.GB6880@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Aug 02, 2002 at 10:02:38AM -0500, Matthew Grooms wrote: > Eric, > > How traffic will be routed is defined by your near/far encryption > domains that were configured via setkey/spdadd directives. These src/dst > domains are compared to packet src/dst to determine if they need to be > encrypted. The IPSEC peer gateway is also defined for each spdadd so > that your gateway knows where to forward the packets after the > ecrypt/encap step. Yep. > This works a bit different for gif enabled tunnels because the IPSEC > peer gateways are actually defined by the private tunnel interface end > points, not the publicly routable interfaces. Its also possible to use a > mixture if giff'd and 'vanila' ESP tunnels. I am doing this right now so > I have attached my config script as an example. But why? Is there something this configuration buys you that you don't get when all are "vanilla" ESP tunnels? > > > echo Initializing IPSEC security policies ... > > # create tunnel device > ifconfig gif0 create 2> /dev/null > > # public addresses ( external ) > gifconfig gif0 66.90.146.202 66.68.118.215 > > # private addresses ( internal ) > ifconfig gif0 inet 10.22.200.1 10.1.2.1 netmask 255.255.255.0 > > # delete all existing SPD and SAD entries > setkey -FP > setkey -F > setkey -c << EOF > > spdadd 10.22.200.0/24 10.1.2.0/24 any -P out ipsec > esp/tunnel/10.22.200.1-10.1.2.1/require; > spdadd 10.1.2.0/24 10.22.200.0/24 any -P in ipsec > esp/tunnel/10.1.2.1-10.22.200.1/require; You seem to be doing this backwards from the usual way (or what I think of as the usual way)... and I really do not understand why. You are taking traffic from, 10.22.200.0/24 <-> 10.1.2.0/24 And encapsulating it in an ESP tunnel, 10.22.200.1 <-> 10.1.2.1 Which _then_ gets put into an (unencrypted) gif(4) tunnel, 66.90.146.202 <-> 66.68.118.215 When I think of gif(4) tunnels, I think of people doing, 10.22.200.0/24 <-> 10.1.2.0/24 In a gif(4) tunnel, 66.90.146.202 <-> 66.68.118.215 And then running ESP in _transport_ mode between those same two endpoints. I could also see running a tunnel within a tunnel like you have, but again, I would usually expect the ESP tunnel to be the outer one. > spdadd 10.22.200.0/24 10.20.0.0/16 any -P out ipsec > esp/tunnel/66.90.146.202-65.118.63.252/require; > spdadd 10.20.0.0/16 10.22.200.0/24 any -P in ipsec > esp/tunnel/65.118.63.252-66.90.146.202/require; > > spdadd 10.22.200.0/24 10.21.0.0/16 any -P out ipsec > esp/tunnel/66.90.146.202-65.118.63.252/require; > spdadd 10.21.0.0/16 10.22.200.0/24 any -P in ipsec > esp/tunnel/65.118.63.252-66.90.146.202/require; > > spdadd 10.22.200.0/24 10.23.0.0/16 any -P out ipsec > esp/tunnel/66.90.146.202-65.118.63.252/require; > spdadd 10.23.0.0/16 10.22.200.0/24 any -P in ipsec > esp/tunnel/65.118.63.252-66.90.146.202/require; -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message