From owner-freebsd-net Wed Nov 7 16:49:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from raven.mail.pas.earthlink.net (raven.mail.pas.earthlink.net [207.217.120.39]) by hub.freebsd.org (Postfix) with ESMTP id 121FD37B419 for ; Wed, 7 Nov 2001 16:49:27 -0800 (PST) Received: from dialup-209.247.136.232.dial1.sanjose1.level3.net ([209.247.136.232] helo=blossom.cjclark.org) by raven.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 161dNg-0006jh-00; Wed, 07 Nov 2001 16:49:21 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id fA80mt801347; Wed, 7 Nov 2001 16:48:55 -0800 (PST) (envelope-from cjc) Date: Wed, 7 Nov 2001 16:48:54 -0800 From: "Crist J. Clark" To: Julian Elischer Cc: Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: Fixing ipfw(8)'s 'tee' Message-ID: <20011107164854.D301@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20011107154601.A301@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from julian@elischer.org on Wed, Nov 07, 2001 at 04:15:09PM -0800 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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