From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 18:00:34 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1658037B401; Sun, 20 Apr 2003 18:00:34 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C79C43F85; Sun, 20 Apr 2003 18:00:32 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org (12-234-159-107.client.attbi.com[12.234.159.107]) by sccrmhc02.attbi.com (sccrmhc02) with ESMTP id <200304210100310020027cche>; Mon, 21 Apr 2003 01:00:31 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.8p1/8.12.3) with ESMTP id h3L10Qki001264; Sun, 20 Apr 2003 18:00:30 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.8p1/8.12.8/Submit) id h3L10PwB001263; Sun, 20 Apr 2003 18:00:25 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Sun, 20 Apr 2003 18:00:25 -0700 From: "Crist J. Clark" To: "Jacques A. Vidrine" , Lars Eggert , freebsd-hackers@FreeBSD.org Message-ID: <20030421010025.GB99917@blossom.cjclark.org> References: <20030410161511.GA25681@madman.celabo.org> <20030416052335.GA2519@blossom.cjclark.org> <20030416123621.GC72501@madman.celabo.org> <20030420165538.GA31101@madman.celabo.org> <3EA2D6F5.4060209@isi.edu> <20030420232614.GA41554@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030420232614.GA41554@madman.celabo.org> User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ Subject: Re: Single IP host and IPsec tunnel mode experience X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cjclark@alum.mit.edu List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 01:00:34 -0000 On Sun, Apr 20, 2003 at 06:26:14PM -0500, Jacques A. Vidrine wrote: > On Sun, Apr 20, 2003 at 10:20:53AM -0700, Lars Eggert wrote: > > On 4/20/2003 9:55 AM, Jacques A. Vidrine wrote: > > >On Wed, Apr 16, 2003 at 07:36:21AM -0500, Jacques A. Vidrine wrote: > > > > > >>On Tue, Apr 15, 2003 at 10:23:35PM -0700, Crist J. Clark wrote: > > >> > > >>>'uname -a'? > > >> > > >>The endpoints were both 4.7. > > >> > > >> > > >>>I can't reproduce this on a 4.8 to 4.7 tunnel. On > > >>>192.168.64.70, > > >>> > > >>> spdadd 192.168.64.70/32 10.0.0.0/24 any -P out > > >>> ipsec esp/tunnel/192.168.64.70-192.168.64.20/require; > > >>> spdadd 10.0.0.0/24 192.168.64.70/32 any -P in > > >>> ipsec esp/tunnel/192.168.64.20-192.168.64.70/require; > > >>> > > >>>And on 192.168.64.20, the gateway to 10.0.0.0/24, > > >>> > > >>> spdadd 192.168.64.70/32 10.0.0.0/24 any -P in > > >>> ipsec esp/tunnel/192.168.64.70-192.168.64.20/require; > > >>> spdadd 10.0.0.0/24 192.168.64.70/32 any -P out > > >>> ipsec esp/tunnel/192.168.64.20-192.168.64.70/require; > > >>> > > >>>Works fine. > > >> > > >>Hmm, yes, that appears to be exactly what I'm trying to do. Well, > > >>that's heartening ... it means that there is likely some anomoly in my > > >>environment that is hosing me. Now if only I can figure what it is :-) > > > > > > > > >Oddly enough ... ESP works, AH does not. > > > > Are you going through a NAT box? (Sorry, haven't been following this > > thread closely.) AH includes more of the IP header when computing the > > crypto checksum (compared to ESP), if those fields get diddled by a NAT > > box, the receiver will drop the packets because of bad crypto. One of > > the netstat counters on the receiver will show this. > > No NAT. > > > If you need to authenticate, maybe try using ESP authentication? > > Yes, I believe that's what I tested. e.g. > > 223.223.223.223 117.117.117.117 > esp mode=tunnel spi=40396514(0x26866e25) reqid=0(0x00000000) > E: 3des-cbc 4dafcf14 1e11dd81 4dafcf14 1e11dd81 4dafcf14 1e11dd81 > A: hmac-sha1 4dafcf14 1e11dd81 4dafcf14 1e11dd81 4dafcf14 > seq=0x00000000 replay=4 flags=0x00000000 state=mature > created: Mar 2 07:52:31 2003 current: Mar 2 07:59:28 2003 > diff: 20(s) hard: 30(s) soft: 24(s) > last: hard: 0(s) soft: 0(s) > current: 0(bytes) hard: 0(bytes) soft: 0(bytes) > allocated: 0 hard: 0 soft: 0 > sadb_seq=2 pid=90010 refcnt=1 > > I actually don't need AH ... I was using AH because it is easier to see > what is going on. It's easy to see what's going on in ESP when you define the encryption algorithm as the NULL algorithm. Although I admit it took me a while to figure out that NULL encryption in the setkey(8) syntax is the "simple" algorithm. In fact, would anyone object to, Index: setkey.8 =================================================================== RCS file: /export/freebsd/ncvs/src/usr.sbin/setkey/setkey.8,v retrieving revision 1.24 diff -u -r1.24 setkey.8 --- setkey.8 1 Jan 2003 18:49:03 -0000 1.24 +++ setkey.8 21 Apr 2003 00:41:50 -0000 @@ -563,7 +563,7 @@ algorithm keylen (bits) comment des-cbc 64 esp-old: rfc1829, esp: rfc2405 3des-cbc 192 rfc2451 -simple 0 to 2048 rfc2410 +null-enc 0 to 2048 rfc2410 blowfish-cbc 40 to 448 rfc2451 cast128-cbc 40 to 128 rfc2451 des-deriv 64 ipsec-ciph-des-derived-01 (expired) Index: token.l =================================================================== RCS file: /export/freebsd/ncvs/src/usr.sbin/setkey/token.l,v retrieving revision 1.5 diff -u -r1.5 token.l --- token.l 11 Jun 2001 12:39:28 -0000 1.5 +++ token.l 21 Apr 2003 00:39:41 -0000 @@ -176,6 +176,7 @@ {hyphen}E { PREPROC; return(F_ENC); } des-cbc { PREPROC; yylval.num = SADB_EALG_DESCBC; return(ALG_ENC); } 3des-cbc { PREPROC; yylval.num = SADB_EALG_3DESCBC; return(ALG_ENC); } +null-enc { PREPROC; yylval.num = SADB_EALG_NULL; return(ALG_ENC); } simple { PREPROC; yylval.num = SADB_EALG_NULL; return(ALG_ENC); } blowfish-cbc { PREPROC; yylval.num = SADB_X_EALG_BLOWFISHCBC; return(ALG_ENC); } cast128-cbc { PREPROC; yylval.num = SADB_X_EALG_CAST128CBC; return(ALG_ENC); } The KAME stuff isn't on a vendor branch, not in a contrib/, and not listed in MAINTAINERS. I guess it's OK to make minor changes/bug fixes locally? I did file a PR with KAME for this too. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org