From owner-freebsd-security Wed Nov 29 14:15:53 2000 Delivered-To: freebsd-security@freebsd.org Received: from phalse.2600.com (phalse.2600.COM [216.66.24.2]) by hub.freebsd.org (Postfix) with ESMTP id 4AE3537B698 for ; Wed, 29 Nov 2000 14:15:49 -0800 (PST) Received: from localhost (localhost [[UNIX: localhost]]) by phalse.2600.com (8.8.8/8.8.8) with ESMTP id RAA27658; Wed, 29 Nov 2000 17:11:57 -0500 (EST) Date: Wed, 29 Nov 2000 17:11:57 -0500 (EST) From: Dominick LaTrappe To: Gerhard Sittig Cc: freebsd-security@freebsd.org Subject: Re: filtering ipsec traffic Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In-Reply-To: <20001129185752.O27042@speedy.gsinet> On Wed, 29 Nov 2000 18:57:52 +0100, Gerhard Sittig wrote: > AFAIK it's as follows: > - Your IPsec traffics comes in on tun0 or whatever your external > interface is called > - it then runs through the IPsec code (which you refer to as > "KAME" in the above, I guess) and turns into "regular" IPv4 > packets > - which leave the machine (or go into localhost applications) via > the enc0 interface From what I've gathered so far, it seems like giving ipfilter/ipfw a pass over an 'unwrapped' (de-esp'd and/or de-ah'd and/or de-ipcomp'd) packet is only possible by having that unwrapped packet enter another interface. I think that's what's going on in you scenario (though I'm not familar with the 'enc' interface), and in Cy Schubert's solutions (earlier in this thread). These are all solutions, but it's unfortunate that one of the most basic KAME setups -- using transport mode on individual hosts -- still has the problem. I wonder if it would be wise to reverse the order of things in the IP stack, so that ipfilter/ipfw always sees packets in their unwrapped form. To use the ipfiler example, this removes the ability to filter "proto ah" and "proto esp", but those filters (mainly used to decide "with whom do I speak IPsec?") can be easily incorporated into KAME. It would certainly be easier than the OpenBSD/FreeSWAN solution, which is to work lots of packet-filtering functionality into the IPsec code itself. Can anyone think of a reason why this would be really undesirable? ||| Dominick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message