Date: Wed, 7 Nov 2001 16:48:54 -0800 From: "Crist J. Clark" <cristjc@earthlink.net> To: Julian Elischer <julian@elischer.org> Cc: Luigi Rizzo <rizzo@aciri.org>, freebsd-net@FreeBSD.ORG Subject: Re: Fixing ipfw(8)'s 'tee' Message-ID: <20011107164854.D301@blossom.cjclark.org> In-Reply-To: <Pine.BSF.4.21.0111071614100.71994-100000@InterJet.elischer.org>; from julian@elischer.org on Wed, Nov 07, 2001 at 04:15:09PM -0800 References: <20011107154601.A301@blossom.cjclark.org> <Pine.BSF.4.21.0111071614100.71994-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 07, 2001 at 04:15:09PM -0800, Julian Elischer wrote:
>
>
> 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..
Sorry about the terminology. I said 'passing _up_ the stack' meaning
that the firewall machine treats all 'tee'ed packets as destined for
itself and the packets get sent to ICMP or transport layer
processing. The patch in the original message starts 'tee' packets
over again farther back in the stack's network layer processing.
Perhaps if I put it this way, the rule,
tee 8668 ip from any to any in via if0
Is currently equivalent to,
divert 8668 ip from any to any via if0
fwd 127.0.0.1 ip from any to any via if0
If the 'divert' rule above fed all packets back into the firewall
untouched. Whereas I _think_ it is supposed to be functionally
equivalent to,
divert 8668 ip from any to any via if0
pass ip from any to any via if0
Where the 'divert' rule writes everything back unchanged.
--
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011107164854.D301>