Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 Nov 2001 02:12:41 -0800
From:      "Crist J. Clark" <cristjc@earthlink.net>
To:        freebsd-net@freebsd.org
Subject:   Fixing ipfw(8)'s 'tee'
Message-ID:  <20011107021241.D307@blossom.cjclark.org>

next in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011107021241.D307>