Date: Mon, 6 Oct 2003 16:18:30 -0700 (PDT) From: Kelly Yancey <kbyanc@posi.net> To: Luigi Rizzo <rizzo@icir.org> Cc: ipfw@freebsd.org Subject: Re: [PATCH FOR REVIEW] layer2 ipfw 'fwd' support Message-ID: <20031006160422.H48937-100000@gateway.posi.net> In-Reply-To: <20030922160744.A61711@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031006160422.H48937-100000>