Date: Wed, 7 Nov 2001 16:15:09 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: cjclark@alum.mit.edu Cc: Luigi Rizzo <rizzo@aciri.org>, freebsd-net@FreeBSD.ORG Subject: Re: Fixing ipfw(8)'s 'tee' Message-ID: <Pine.BSF.4.21.0111071614100.71994-100000@InterJet.elischer.org> In-Reply-To: <20011107154601.A301@blossom.cjclark.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 7 Nov 2001, Crist J. Clark wrote: > On Wed, Nov 07, 2001 at 09:34:04AM -0800, Luigi Rizzo wrote: > > On Wed, Nov 07, 2001 at 02:12:41AM -0800, Crist J. Clark wrote: > > ... > > > About 'accepted,' but I don't believe this is the intended > > > behavior. For outgoing packets, one copy is sent to the divert port > > > and the other is routed to the destination on the packet. > > ... > > > I'm not really sure if I understand what 'tee' is needed for. Why > > > not just have whatever is listening on the 'tee' divert socket write > > > packets back in? This also works around the issue that 'tee' packets > > > are immediately accepted by the firewall. But if we want to keep > > > 'tee,' it probably should work. > > > > for sure we can replace tee with divert as you say, but then > > you would depend on the userland app to do its work (and you > > could have drops on the divert socket, whereas forwarding within > > the kernel is much faster). > > > > There is not an issue of accept vs. deny a "tee" packet, if > > you want to deny it you just use a "divert" rule instead. > > The issue may be that you wish to make a decision on the packet in > later rules. For example, someone might wish to 'tee' all traffic to > and from a certain machine to some unspecified traffic monitoring > program listening on the divert socket. However, all of the traffic > too and from that IP address may or may not be allowed by the security > policy. With 'tee' as it exists, one cannot catch _all_ of the traffic > (whether or not allowed by policy) and still apply policy. > > But does everyone agree the current behavior of 'tee' is broken? The > firewall should not be passing packets not destined for itself up the > stack; it should be forwarding them, right? Forwarding is achieved by passing it to the stack. It's the stack that decides to forward.. > -- > Crist J. Clark | cjclark@alum.mit.edu > | cjclark@jhu.edu > http://people.freebsd.org/~cjc/ | cjc@freebsd.org > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0111071614100.71994-100000>