Date: Wed, 29 Nov 2000 17:11:57 -0500 (EST) From: Dominick LaTrappe <seraf@2600.COM> To: Gerhard Sittig <Gerhard.Sittig@gmx.net> Cc: freebsd-security@freebsd.org Subject: Re: filtering ipsec traffic Message-ID: <Pine.NEB.4.21.0011291638050.27399-100000@phalse.2600.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.4.21.0011291638050.27399-100000>