Date: Mon, 16 Apr 2001 21:09:50 +0100 From: Brian Candler <B.Candler@pobox.com> To: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> Cc: Lowell Gilbert <lowell@world.std.com>, Rasputin <rara.rasputin@virgin.net>, freebsd-security@FreeBSD.ORG Subject: Re: Interaction between ipfw, IPSEC and natd Message-ID: <20010416210950.A14903@linnet.org> In-Reply-To: <200104161914.f3GJEMh06453@cwsys.cwsent.com>; from Cy.Schubert@uumail.gov.bc.ca on Mon, Apr 16, 2001 at 12:14:05PM -0700 References: <20010416112358.A13561@linnet.org> <200104161914.f3GJEMh06453@cwsys.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 16, 2001 at 12:14:05PM -0700, Cy Schubert - ITSD Open Systems Group wrote: > I've noticed this with IP Filter as well. For applications where this > is a critical issue, I use the pipsecd port, allowing me to filter on > the external interface (xl0, fxp0, etc), e.g. AH and ESP, and the > tun(4) interface that pipsecd is attached to, e.g. TCP, UDP, ICMP. Ah yes, that's one solution. But pipsecd is limited, e.g. it only supports manually-keyed tunnels AFAIK. A userland implementation like pipsecd, but which used a divert(4) socket like natd, would be cool. Then the sequence of protocol processing would be explicit in the ipfw ruleset. However I can see ipfw becoming less used as people move to ipf(ilter) these days. At least the interaction between ipf and ipnat is documented, if not with IPSEC: http://coombs.anu.edu.au/~avalon/ipfil-flow.html > I realise that this was discussed on this list within the past 6 months > and that one the KAME developers (KAME is obviously IPv6 focused) > indicated that IPv6 addressing would not allow for IPSec packets being > filtered on an interface because IPv6 addresses span all interfaces. Hmm, I don't think that's right. In general, IPv6 addresses _are_ specific to an interface just like IPv4, apart from some special addresses, e.g. link-local and loopback, or multicast. And in any case, a packet coming in through (say) fxp0 can still be tagged as coming in through fxp0. There is even a standard syntax for supporting link-local addresses on a specific interface: e.g. # ping6 fe80::260:97ff:fe40:efab%fxp0 Brian. 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?20010416210950.A14903>