From owner-freebsd-ipfw@FreeBSD.ORG Mon Oct 6 16:18:35 2003 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63D4316A4B3 for ; Mon, 6 Oct 2003 16:18:35 -0700 (PDT) Received: from gateway.posi.net (adsl-63-201-92-171.dsl.snfc21.pacbell.net [63.201.92.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12F1B43FFD for ; Mon, 6 Oct 2003 16:18:34 -0700 (PDT) (envelope-from kbyanc@posi.net) Received: from localhost (localhost [127.0.0.1]) by gateway.posi.net (8.12.9/8.12.8) with ESMTP id h96NIUe7049044; Mon, 6 Oct 2003 16:18:32 -0700 (PDT) (envelope-from kbyanc@posi.net) Date: Mon, 6 Oct 2003 16:18:30 -0700 (PDT) From: Kelly Yancey To: Luigi Rizzo In-Reply-To: <20030922160744.A61711@xorpc.icir.org> Message-ID: <20031006160422.H48937-100000@gateway.posi.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: ipfw@freebsd.org Subject: Re: [PATCH FOR REVIEW] layer2 ipfw 'fwd' support X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2003 23:18:35 -0000 On Mon, 22 Sep 2003, Luigi Rizzo wrote: > hi, > for those interested in using ipfw 'fwd' instructions in a bridge > (e.g. to create a transparent proxy with a bridge) here is a patch > to try for ip_fw2.c (and a trivial one-line change in ip_input.c) > > The change to ip_input.c matches more closely what the comment says: > if the packet is tagged by the firewall as 'PACKET_TAG_IPFORWARD' > than you skip the pass through the firewall, but still check to see > where the packet goes. > > The ip_fw2.c change does the following: when the bridge detects a > layer2 packet, it passes it to ip_input() [!!!layering violation!!!] > with a proper tag so that the packet is subject to the same processing > it would have in a router. > > [BTW i believe the same approach could be used to implement 'divert' > within a bridge if we only care for IP packets -- i.e. we tag the > packet and pass it to the upper layer] > When I implemented this functionality in our company's local tree, I used a check like: if (args->eh && oif != NULL) { /* ignore outbound layer2 pkts */ goto next_rule; } in the O_FORWARD_IP case to prevent loops when the 'fwd' target was on the same machine. In that case, reply packets from the application forwarded to would get forwarded to itself unless you explicitely added a 'in' qualifier to the 'fwd' rule. The other issue I ran into when I implemented 'fwd' and 'divert' from layer-2 were spl issues since the layer-2 firewall runs at splimp() while everything at layer-3 is splnet(), so if the target application was on the same machine, it could corrupt the socket buffers reading/writing while packets were added/removed at splimp(). With -current this might not be much of an issue since mutexes are used for protection, but in our codebase build on -stable I had to do some mild hackery to get the packet into the NETISP_IP queue. Kelly -- Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} -- kelly@nttmcl.com