Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Oct 2001 02:35:47 -0700
From:      "Crist J. Clark" <cristjc@earthlink.net>
To:        Tim Burgess <tburgess@whitley.unimelb.edu.au>
Cc:        freebsd-gnats-submit@FreeBSD.ORG, freebsd-net@FreeBSD.ORG
Subject:   Re: kern/31130: ipfw tee functionality causes malfunction and security hole
Message-ID:  <20011010023547.I387@blossom.cjclark.org>
In-Reply-To: <200110090920.f999K2X17814@freefall.freebsd.org>; from cristjc@earthlink.net on Tue, Oct 09, 2001 at 02:20:02AM -0700
References:  <200110090920.f999K2X17814@freefall.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 09, 2001 at 02:20:02AM -0700, Crist J. Clark wrote:

[snip]

>  On the wire and the packets never get routed to the "real" 172.16.0.1.
>  Trying to figure out if,
>  
>    a) This is the expected behavior, but is poorly documented, or
>    b) Something is broken.
>  
>  I'm thinking (b), but still wading through src/sys/netinet to verify.

Well, I see why this happens, but still not sure if it is supposed to
happen. If we look at src/sys/netinet/ip_input.c, we see that all
diverted or teed packets are accepted by the host as destined for
itself,

#ifdef IPDIVERT
		if (i != 0 && (i & IP_FW_PORT_DYNT_FLAG) == 0) {
			/* Divert or tee packet */
			divert_info = i;
			goto ours;
		}
#endif

The packets are clearly going to be processed by the gateway. You seem
to have already found this in the code snipped in your original PR,
but I didn't notice your change. Please post changes to code as
unified diffs. I now understand the 'fix' you were talking about. Have
you actually built a kernel with your modifications? Does it seem to
work?

But packets _leaving_ the system seem to be processed as one would
expect. That is, a copy is divert(4)ed and then the packet heads out
onto to the wire.

This apparent inconsistency is a bug since it is either unintended
behavior or at least undocumented behavior. But the inconsistency
gives you a temporary workaround. Instead of,

  600 tee 8665 ip from any to any in

Does,

  600 tee 8665 ip from any to any out

Work as you would expect?
-- 
Crist J. Clark                           cjclark@alum.mit.edu
                                         cjclark@jhu.edu
                                         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?20011010023547.I387>