From owner-freebsd-net Wed Nov 7 2:34: 4 2001 Delivered-To: freebsd-net@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id E3FFD37B416 for ; Wed, 7 Nov 2001 02:34:00 -0800 (PST) Received: from dialup-209.247.138.98.dial1.sanjose1.level3.net ([209.247.138.98] helo=blossom.cjclark.org) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 161Q1m-00070e-00 for freebsd-net@freebsd.org; Wed, 07 Nov 2001 02:33:51 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id fA7ACfd00802 for freebsd-net@freebsd.org; Wed, 7 Nov 2001 02:12:41 -0800 (PST) (envelope-from cjc) Date: Wed, 7 Nov 2001 02:12:41 -0800 From: "Crist J. Clark" To: freebsd-net@freebsd.org Subject: Fixing ipfw(8)'s 'tee' Message-ID: <20011107021241.D307@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i 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 The 'tee' action in ipfw(8) is presently broken (see PR kern/31130). All incoming packets are accepted by the firewall machine. That is, one copy is sent to the divert socket and another copy is passed up the stack of the firewall machine. The copy is not routed to the final destination on the IP packet. The manual is slightly ambiguous, tee port Send a copy of packets matching this rule to the divert(4) socket bound to port port. The search termi- nates and the original packet is accepted (but see sec- tion BUGS below). 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. The following simple patch to ip_input.c appears to fix the problem, but I wanted to make sure that this really is the intended behavior. Packets that match the 'tee' rule have one copy sent to the divert port and a second copy is accepted by the firewall rules. That is, accepted as if it hit a 'pass' rule, and not accepted by the firewall host and passed up the stack. In addition, I want to state a little more clearly that 'tee' and 'divert' rules cause fragmented datagrams to be reassembled before they are further processed. I think someone using 'tee' might be fooled into believing the copies that stay in the stack have not been reassembled like the ones going to the divert socket. They have been. 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. Index: src/sys/netinet/ip_input.c =================================================================== RCS file: /export/ncvs/src/sys/netinet/ip_input.c,v retrieving revision 1.183 diff -u -r1.183 ip_input.c --- src/sys/netinet/ip_input.c 2001/10/25 06:27:51 1.183 +++ src/sys/netinet/ip_input.c 2001/11/07 09:51:09 @@ -794,6 +794,9 @@ return; m = clone; ip = mtod(m, struct ip *); + ip->ip_len += hlen; + divert_info = 0; + goto pass; } #endif Index: ipfw.8 =================================================================== RCS file: /export/ncvs/src/sbin/ipfw/ipfw.8,v retrieving revision 1.93 diff -u -r1.93 ipfw.8 --- ipfw.8 2001/10/14 22:46:05 1.93 +++ ipfw.8 2001/11/07 10:06:11 @@ -1359,7 +1359,11 @@ .Cm divert or .Cm tee -are reassembled before delivery to the socket. +are reassembled before delivery to the socket. The packet copied by +.Cm tee +back into the network stack has also been reassembled. Note that +reassembly of forwarded packets technically violates the Internet +Standards for routers. .Pp Packets that match a .Cm tee -- 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