From owner-freebsd-ipfw Sat Sep 22 8:58:54 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from nollie.summersault.com (nollie.summersault.com [208.10.44.140]) by hub.freebsd.org (Postfix) with SMTP id 51EF937B415 for ; Sat, 22 Sep 2001 08:58:29 -0700 (PDT) Received: (qmail 34812 invoked by uid 1001); 22 Sep 2001 15:58:28 -0000 Date: Sat, 22 Sep 2001 10:58:28 -0500 (EST) From: Chris Hardie To: Luigi Rizzo Cc: freebsd-hackers@FreeBSD.ORG, , Subject: Re: net.inet.ip.fw.one_pass=0 not effective in filtering bridge? In-Reply-To: <200109221508.RAA66779@info.iet.unipi.it> Message-ID: X-Request-PGP: http://www.summersault.com/chris/me/pgp-pubring.txt MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Luigi, I don't currently have a box I can experiment with, but I'll try to put something together. Do you have a sense of how "risky" your proposed change is? :) In any case, I might recommend an update to the dummynet(4) man page that clarifies this behavior. These two excerpts: "When acting as a bridge, the ipfw filter is invoked only once, in the in- put path, for bridged packets." AND "Depending on the setting of the sysctl variable `net.inet.ip.fw.one_pass', packets coming from a pipe can be either forwarded to their destination, or passed again through the ipfw rules, starting from the one after the matching rule." could probably be more proximal to each other, and/or you could explicitly state that the sysctl variable has no effect in current bridging. I see that you've done this on your ip_dummynet section of your personal website: "NOTE: there is always one pass for bridged packets." It may also be useful to explicitly state this in the Filtering Bridges article by Nick Sayer: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/filtering-bridges/filtering-bridges-ipfirewall.html My concern is that typical users won't read or test closely enough to know this, and will assume that their dummynet bridges are working the way I thought mine was. Thanks, Chris On Sat, 22 Sep 2001, Luigi Rizzo wrote: > in fact one_pass does not work with bridging, > it might be as simple as changing one line in bridge.c > > if (ip_fw_chk_ptr && bdg_ipfw != 0 && src != NULL) { > struct ip *ip ; > int i; > > - if (rule != NULL) /* dummynet packet, already partially processed */ > + if (rule != NULL && fw_one_pass) > goto forward; /* HACK! I should obey the fw_one_pass */ > > but i never had a chance to test it. > If you want to give this a try, I'd be glad to know how it works. > > cheers > luigi > > > Hi. I've got a filtering bridge running on FreeBSD 4.3 with ipfw and > > a customized rc.firewall config. The setup has been working well for > > a while now. I was unfortunately alerted to a hole after a box behind > > the firewall was cracked because ports that I thought were > > protected...weren't. > > > > It turns out that traffic to/from the machine in question was being > > passed through a pipe early in the rc.firewall config, and that the > > ipfw processing terminated when the packets came out of the pipe, so > > they never saw the rules farther down that would have dropped those > > packets headed for bad places. > > > > A-ha! "Easy" you say - just do > > sysctl -w net.inet.ip.fw.one_pass=0 > > and according to the ipfw man page, that will cause the packets to be > > re-injected into the firewall when they come out of the pipe, starting > > where they left off. Well, this just doesn't seem to be taking > > effect! > > > > I've crawled through docs and mailing lists. Setting > > net.inet.ip.fw.one_pass seems to be the common solution, but a few > > other people have mentioned the same ineffectiveness of that, and then > > those threads just drop off. So I'm wondering if it's possible that, > > because the kernel is compiled with "options BRIDGE", that packets are > > strictly only going through the firewall rules once, and that > > net.inet.ip.fw.one_pass=0 isn't having an effect in this case? > > > > If my wondering is in error, I'm looking for suggestions about how to > > verify the behavior I'm seeing and how to achieve the desired result: to > > use pipes AND deny rules that come after. I'm happy to send along the > > particular rules, but wanted to see if the question could be answered > > using theory first. > > > > (This message addresses an issue similar to but separate from the "ipfw" > > thread on freebsd-questions started by Rick Norman on Sep 18. I also > > posted this message there.) > > > > Any help is much appreciated. > > > > Thanks, > > Chris > > > > -- Chris Hardie ----------------------------- > > ----- mailto:chris@summersault.com ---------- > > -------- http://www.summersault.com/chris/ -- > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message