From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 13:59:09 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 46DA137B401; Sun, 20 Apr 2003 13:59:09 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A0FE43FDD; Sun, 20 Apr 2003 13:59:08 -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 sccrmhc01.attbi.com (sccrmhc01) with ESMTP id <2003042020590600100a4j6ge>; Sun, 20 Apr 2003 20:59:06 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.8p1/8.12.3) with ESMTP id h3KKx5ki000369; Sun, 20 Apr 2003 13:59:05 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.8p1/8.12.8/Submit) id h3KKx5om000368; Sun, 20 Apr 2003 13:59:05 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Sun, 20 Apr 2003 13:59:01 -0700 From: "Crist J. Clark" To: "Jacques A. Vidrine" , freebsd-hackers@FreeBSD.org Message-ID: <20030420205901.GA99917@blossom.cjclark.org> References: <20030410161511.GA25681@madman.celabo.org> <20030416052335.GA2519@blossom.cjclark.org> <20030416123621.GC72501@madman.celabo.org> <20030420165538.GA31101@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030420165538.GA31101@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: Sun, 20 Apr 2003 20:59:09 -0000 On Sun, Apr 20, 2003 at 11:55:38AM -0500, 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. Yep, I can reproduce that. This setup, bubbles# cat bubbles.spd # Security Policy Database 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; # Security Associations Database add 192.168.64.70 192.168.64.20 esp 0x4321 -m tunnel -r 128 -E rijndael-cbc "encryption keys1" -A hmac-md5 "testkey1testkey2"; add 192.168.64.20 192.168.64.70 esp 0x1234 -m tunnel -r 128 -E rijndael-cbc "encryption keys2" -A hmac-md5 "testkey2testkey1"; Works great with the apropriate swapping in the SPD on the other end of the tunnel. However, do the following to both, bubbles# ed bubbles.spd g/esp/s/esp/ah/ g/-E/s/^/#/ wq bubbles# setkey -F; setkey -FP; setkey -f bubbles.spd And things do not work. The sender seems to work fine, but the receiver increments the, "inbound packets violated process security policy" Counter. But the really puzzling part is that it increments the, "inbound packets processed successfully" (which I think I understand) "inbound packets considered authentic" (which I do not) Counters too. Your conjecture that it may be somehow processing inbound packets twice may be on the right track. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org