From owner-freebsd-ipfw Thu Jan 4 5:32:45 2001 From owner-freebsd-ipfw@FreeBSD.ORG Thu Jan 4 05:32:41 2001 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from newmail.netbistro.com (newmail.netbistro.com [204.239.167.35]) by hub.freebsd.org (Postfix) with SMTP id 473FE37B400 for ; Thu, 4 Jan 2001 05:32:41 -0800 (PST) Received: (qmail 22623 invoked by uid 1020); 4 Jan 2001 13:32:37 -0000 Date: Thu, 4 Jan 2001 05:32:37 -0800 (PST) From: Jon Simola X-Sender: jon@newmail.netbistro.com To: ipfw@freebsd.org Subject: Indexing IPFW rule Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1679715968-978615157=:462" Sender: jon@netbistro.com Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1679715968-978615157=:462 Content-Type: TEXT/PLAIN; charset=US-ASCII I have a bridging firewall in place, and I needed to be able to allow and deny traffic from single IPs and change whether they're allowed or denied rather quickly. Looking through the IPFW code at the skipto rule, I figured it couldn't be too hard. This (very rough) code actually does the job (albeit in only one direction currently). It's designed to be used like: ipfw add 9000 index 10000 ip from any to 192.168.0.0/24 in recv rl0 # make sure you don't fall through into this block of rules ipfw add 10001 allow ip from any to any # 192.168.0.1 will be thrown here ipfw add 10002 deny ip from any to any # 192.168.0.2 will be thrown here # skip a few for readability ipfw add 10254 deny ip from any to any # 192.168.0.254 will be thrown here ipfw add 10255 allow ip from any to any # 192.168.0.255 will be thrown here Now, I'm hoping to garner some feedback on: - ways to clean up the code - things to improve (besides it's current unidirectional nature) - whether this is interesting Oh, it's a patch against 4.2-RELEASE. Thanks! --- Jon Simola | "In the near future - corporate networks Systems Administrator | reach out to the stars, electrons and light ABC Communications | flow throughout the universe." -- GITS --0-1679715968-978615157=:462 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="firewallindex.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: firewallindex.diff DQotLS0gc3lzL25ldGluZXQvaXBfZncuYy5vcmlnCVRodSBKYW4gIDQgMDI6 Mjc6MDQgMjAwMQ0KKysrIHN5cy9uZXRpbmV0L2lwX2Z3LmMJVGh1IEphbiAg NCAwNDozMzo1MiAyMDAxDQpAQCAtNTA2LDYgKzUwNiwxMCBAQA0KIAkJICAg IHNucHJpbnRmKFNOUEFSR1MoYWN0aW9uMiwgMCksICJTa2lwVG8gJWQiLA0K IAkJCWYtPmZ3X3NraXB0b19ydWxlKTsNCiAJCSAgICBicmVhazsNCisJICAg IGNhc2UgSVBfRldfRl9JTkRFWDoNCisJCSAgICBzbnByaW50ZihTTlBBUkdT KGFjdGlvbjIsIDApLCAiSW5kZXggJWQiLA0KKwkJCWYtPmZ3X3NraXB0b19y dWxlKTsNCisJCSAgICBicmVhazsNCiAjaWZkZWYgRFVNTVlORVQNCiAJICAg IGNhc2UgSVBfRldfRl9QSVBFOg0KIAkJICAgIHNucHJpbnRmKFNOUEFSR1Mo YWN0aW9uMiwgMCksICJQaXBlICVkIiwNCkBAIC04NzgsNiArODgyLDI5IEBA DQogfQ0KIA0KIC8qDQorICogZ2l2ZW4gYW4gaXBfZndfY2hhaW4gKiwgbG9v a3VwX2luZGV4X3J1bGUgd2lsbCByZXR1cm4gYSBwb2ludGVyDQorICogb2Yg dGhlIHNhbWUgdHlwZSB0byB0aGUgbmV4dCBvbmUuIFRoaXMgY2FuIGJlIGVp dGhlciB0aGUgaW5kZXgNCisgKiB0YXJnZXQgKGZvciBpbmRleCBpbnN0cnVj dGlvbnMpIG9yIHRoZSBuZXh0IG9uZSBpbiB0aGUgY2hhaW4gKGluDQorICog YWxsIG90aGVyIGNhc2VzIGluY2x1ZGluZyBhIG1pc3NpbmcganVtcCB0YXJn ZXQpLg0KKyAqIEJhY2t3YXJkIGp1bXBzIGFyZSBub3QgYWxsb3dlZCwgc28g c3RhcnQgbG9va2luZyBmcm9tIHRoZSBuZXh0DQorICogcnVsZS4uLg0KKyAq LyANCitzdGF0aWMgc3RydWN0IGlwX2Z3X2NoYWluICogbG9va3VwX2luZGV4 X3J1bGUoc3RydWN0IGlwX2Z3X2NoYWluICptZSwgdV9pbnQzMl90IGRzdF9p cCk7DQorDQorc3RhdGljIHN0cnVjdCBpcF9md19jaGFpbiAqDQorbG9va3Vw X2luZGV4X3J1bGUoc3RydWN0IGlwX2Z3X2NoYWluICptZSwgdV9pbnQzMl90 IGRzdF9pcCkNCit7DQorICAgIHN0cnVjdCBpcF9md19jaGFpbiAqY2hhaW4g Ow0KKyAgICBpbnQgcnVsZSA9IG1lLT5ydWxlLT5md19za2lwdG9fcnVsZSAr ICgoZHN0X2lwPj4yNCkgJiBJTl9DTEFTU0NfSE9TVCk7IC8qIGd1ZXNzLi4u ICovDQorICAgIGlmICggKG1lLT5ydWxlLT5md19mbGcgJiBJUF9GV19GX0NP TU1BTkQpID09IElQX0ZXX0ZfSU5ERVggKQ0KKwlmb3IgKGNoYWluID0gbWUt PmNoYWluLmxlX25leHQ7IGNoYWluIDsgY2hhaW4gPSBjaGFpbi0+Y2hhaW4u bGVfbmV4dCApDQorCSAgICBpZiAoY2hhaW4tPnJ1bGUtPmZ3X251bWJlciA+ PSBydWxlKQ0KKyAgICAgICAgICAgICAgICByZXR1cm4gY2hhaW4gOw0KKyAg ICByZXR1cm4gbWUtPmNoYWluLmxlX25leHQgOyAvKiBmYWlsdXJlIG9yIG5v dCBhIHNraXB0byAqLw0KK30NCisNCisNCisvKg0KICAqIFBhcmFtZXRlcnM6 DQogICoNCiAgKglwaXAJUG9pbnRlciB0byBwYWNrZXQgaGVhZGVyIChzdHJ1 Y3QgaXAgKiopDQpAQCAtMTMwNCw2ICsxMzMxLDEzIEBADQogCQkJICAgIGNo YWluID0gbG9va3VwX25leHRfcnVsZShjaGFpbikgOw0KIAkJCWlmICghIGNo YWluKSBnb3RvIGRyb3BpdDsNCiAJCQlnb3RvIGFnYWluIDsNCisJCWNhc2Ug SVBfRldfRl9JTkRFWDogLyogZHN0X2lwICovDQorCQkJaWYgKCBmLT5uZXh0 X3J1bGVfcHRyICkNCisJCQkgICAgY2hhaW4gPSBmLT5uZXh0X3J1bGVfcHRy IDsNCisJCQllbHNlDQorCQkJICAgIGNoYWluID0gbG9va3VwX2luZGV4X3J1 bGUoY2hhaW4sIGRzdF9pcC5zX2FkZHIpIDsNCisJCQlpZiAoISBjaGFpbikg Z290byBkcm9waXQ7DQorCQkJZ290byBhZ2FpbiA7DQogI2lmZGVmIERVTU1Z TkVUDQogCQljYXNlIElQX0ZXX0ZfUElQRToNCiAJCWNhc2UgSVBfRldfRl9R VUVVRToNCkBAIC0xNzQ0LDYgKzE3NzgsNyBAQA0KIAljYXNlIElQX0ZXX0Zf QUNDRVBUOg0KIAljYXNlIElQX0ZXX0ZfQ09VTlQ6DQogCWNhc2UgSVBfRldf Rl9TS0lQVE86DQorCWNhc2UgSVBfRldfRl9JTkRFWDoNCiAjaWZkZWYgSVBG SVJFV0FMTF9GT1JXQVJEDQogCWNhc2UgSVBfRldfRl9GV0Q6DQogI2VuZGlm DQoNCi0tLSBzeXMvbmV0aW5ldC9pcF9mdy5oLm9yaWcJTW9uIEF1ZyAyMSAx NzozMzoxOCAyMDAwDQorKysgc3lzL25ldGluZXQvaXBfZncuaAlUaHUgSmFu ICA0IDAyOjI2OjA4IDIwMDENCkBAIC0xNjgsNiArMTY4LDcgQEANCiAjZGVm aW5lIElQX0ZXX0ZfRldECTB4MDAwMDAwMDcJLyogVGhpcyBpcyBhICJjaGFu Z2UgZm9yd2FyZGluZyBhZGRyZXNzIiBydWxlICovDQogI2RlZmluZSBJUF9G V19GX1BJUEUJMHgwMDAwMDAwOAkvKiBUaGlzIGlzIGEgZHVtbXluZXQgcnVs ZSAqLw0KICNkZWZpbmUgSVBfRldfRl9RVUVVRQkweDAwMDAwMDA5CS8qIFRo aXMgaXMgYSBkdW1teW5ldCBxdWV1ZSAqLw0KKyNkZWZpbmUgSVBfRldfRl9J TkRFWAkweDAwMDAwMDBBCS8qIFRoaXMgaXMgYSBpbmRleCBydWxlICovDQog DQogI2RlZmluZSBJUF9GV19GX0lOCTB4MDAwMDAxMDAJLyogQ2hlY2sgaW5i b3VuZCBwYWNrZXRzCQkqLw0KICNkZWZpbmUgSVBfRldfRl9PVVQJMHgwMDAw MDIwMAkvKiBDaGVjayBvdXRib3VuZCBwYWNrZXRzCQkqLw0KDQotLS0gc2Jp bi9pcGZ3L2lwZncuYy5vcmlnCVRodSBKYW4gIDQgMDM6MDI6MjQgMjAwMQ0K KysrIHNiaW4vaXBmdy9pcGZ3LmMJVGh1IEphbiAgNCAwMzowNDoyMCAyMDAx DQpAQCAtMjQxLDYgKzI0MSw5IEBADQogCQljYXNlIElQX0ZXX0ZfU0tJUFRP Og0KIAkJCXByaW50Zigic2tpcHRvICV1IiwgY2hhaW4tPmZ3X3NraXB0b19y dWxlKTsNCiAJCQlicmVhazsNCisJCWNhc2UgSVBfRldfRl9JTkRFWDoNCisJ CQlwcmludGYoImluZGV4ICV1IiwgY2hhaW4tPmZ3X3NraXB0b19ydWxlKTsN CisJCQlicmVhazsNCiAgICAgICAgICAgICAgICAgY2FzZSBJUF9GV19GX1BJ UEU6DQogICAgICAgICAgICAgICAgICAgICAgICAgcHJpbnRmKCJwaXBlICV1 IiwgY2hhaW4tPmZ3X3NraXB0b19ydWxlKTsNCiAgICAgICAgICAgICAgICAg ICAgICAgICBicmVhayA7DQpAQCAtMTY0OCw2ICsxNjUxLDExIEBADQogCQly dWxlLmZ3X2ZsZyB8PSBJUF9GV19GX1NLSVBUTzsgYXYrKzsgYWMtLTsNCiAJ CWlmICghYWMpDQogCQkJc2hvd191c2FnZSgibWlzc2luZyBza2lwdG8gcnVs ZSBudW1iZXIiKTsNCisJCXJ1bGUuZndfc2tpcHRvX3J1bGUgPSBzdHJ0b3Vs KCphdiwgTlVMTCwgMCk7IGF2Kys7IGFjLS07DQorCX0gZWxzZSBpZiAoIXN0 cm5jbXAoKmF2LCJpbmRleCIsc3RybGVuKCphdikpKSB7DQorCQlydWxlLmZ3 X2ZsZyB8PSBJUF9GV19GX0lOREVYOyBhdisrOyBhYy0tOw0KKwkJaWYgKCFh YykNCisJCQlzaG93X3VzYWdlKCJtaXNzaW5nIGluZGV4IHJ1bGUgbnVtYmVy Iik7DQogCQlydWxlLmZ3X3NraXB0b19ydWxlID0gc3RydG91bCgqYXYsIE5V TEwsIDApOyBhdisrOyBhYy0tOw0KIAl9IGVsc2UgaWYgKCghc3RybmNtcCgq YXYsImRlbnkiLHN0cmxlbigqYXYpKQ0KIAkJICAgIHx8ICFzdHJuY21wKCph diwiZHJvcCIsc3RybGVuKCphdikpKSkgew0KDQo= --0-1679715968-978615157=:462-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Jan 4 6:34:24 2001 From owner-freebsd-ipfw@FreeBSD.ORG Thu Jan 4 06:34:22 2001 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 50C4B37B400 for ; Thu, 4 Jan 2001 06:34:22 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f04EYC189940; Thu, 4 Jan 2001 06:34:12 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200101041434.f04EYC189940@iguana.aciri.org> Subject: Re: Indexing IPFW rule In-Reply-To: from Jon Simola at "Jan 4, 2001 5:32:37 am" To: jon@abccom.bc.ca (Jon Simola) Date: Thu, 4 Jan 2001 06:34:12 -0800 (PST) Cc: ipfw@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: rizzo@iguana.aciri.org Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The idea in principle is ok, but your implementation is rather expensive at runtime, as you have to scan the list of rules every time you match a packet. I think this is too expensive in practice. Your code below seems to try and use the "next_rule_ptr" field which i introduced some time ago to cache the jump target in skipto rules, but this is not enough for your rules -- basically the 'if' branch should be never taken. > + case IP_FW_F_INDEX: /* dst_ip */ > + if ( f->next_rule_ptr ) > + chain = f->next_rule_ptr ; > + else > + chain = lookup_index_rule(chain, dst_ip.s_addr) ; > + if (! chain) goto dropit; > + goto again ; Another problem in your code is that you hardwire the mask to 24 bit in the code, this can be confusing. There are some ways to solve the efficiency problem, but probably the simplest one is to to keep your code but put a "keep-state" option in each of the branch targets and in the index rule -- this way the matching will install a dynamic rule which can be then tested in O(1) time because this is supported by a hash table. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Jan 4 9:24:47 2001 From owner-freebsd-ipfw@FreeBSD.ORG Thu Jan 4 09:24:44 2001 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 8D18E37B400 for ; Thu, 4 Jan 2001 09:24:44 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f04HOgc92175; Thu, 4 Jan 2001 09:24:42 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200101041724.f04HOgc92175@iguana.aciri.org> Subject: Re: Indexing IPFW rule In-Reply-To: <200101041434.f04EYC189940@iguana.aciri.org> from Luigi Rizzo at "Jan 4, 2001 6:34:12 am" To: rizzo@aciri.org (Luigi Rizzo) Date: Thu, 4 Jan 2001 09:24:41 -0800 (PST) Cc: jon@abccom.bc.ca, ipfw@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: rizzo@iguana.aciri.org Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG on second thought... unless you find some more efficient way to perform the first matching, the "index" ipfw action seems completely overkill if you use dynamic rules: just put a check-state first, followed by an ordinary skipto to go to the beginning of the table, and then insert all rules you need. This is extremely flexible, as you can use different patterns on the "jump table" (which is not a jump table anymore) and quite efficient after the first time because the check-state matches quickly. ipfw add 1000 check-state ipfw add 1001 skipto 10000 ... ipfw add 10000 allow ip from 10.0.0.1 to any ipfw add 10000 deny ip from 10.0.0.2 to any ipfw add 10000 deny ip from 10.0.0.3 to any ipfw add 10000 allow ip from 10.0.0.4/28 to any ... ipfw add 10000 allow ip from 10.0.0.254 to any > There are some ways to solve the efficiency problem, but probably > the simplest one is to to keep your code but put a "keep-state" > option in each of the branch targets and in the index rule -- this > way the matching will install a dynamic rule which can be then > tested in O(1) time because this is supported by a hash table. > > cheers > luigi > ----------------------------------+----------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) > http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 > Phone: (510) 666 2927 > ----------------------------------+----------------------------------------- > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Jan 4 16: 5: 1 2001 From owner-freebsd-ipfw@FreeBSD.ORG Thu Jan 4 16:04:58 2001 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from newmail.netbistro.com (newmail.netbistro.com [204.239.167.35]) by hub.freebsd.org (Postfix) with SMTP id 4519237B400 for ; Thu, 4 Jan 2001 16:04:58 -0800 (PST) Received: (qmail 21090 invoked by uid 1020); 5 Jan 2001 00:04:17 -0000 Date: Thu, 4 Jan 2001 16:04:17 -0800 (PST) From: Jon Simola X-Sender: jon@newmail.netbistro.com To: Luigi Rizzo Cc: ipfw@FreeBSD.ORG Subject: Re: Indexing IPFW rule In-Reply-To: <200101041724.f04HOgc92175@iguana.aciri.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: jon@netbistro.com Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 4 Jan 2001, Luigi Rizzo wrote: > on second thought... unless you find some more efficient way to > perform the first matching, the "index" ipfw action seems completely > overkill if you use dynamic rules: just put a check-state first, > followed by an ordinary skipto to go to the beginning of the table, > and then insert all rules you need. This is extremely flexible, as > you can use different patterns on the "jump table" (which is not > a jump table anymore) and quite efficient after the first time > because the check-state matches quickly. Yep, it's just that initial match that isn't pretty, and not simple to implement. Currently, for each /24 I've got 256 rules for inbound and 256 for outbound traffic, and 84 rules each way (arranged in a 3 level quad-tree) to jump into those rule blocks (gives me the wonderful side effect of traffic stats as well). I'm running full duplex 100Meg through a PPro 180, so I'm very interested in speeding the firewall up as much as possible. That's why I did the index idea, it's basically a skipto with a variable destination, and it's a *lot* easier to comprehend than my nasty collection of skipto rules arranged in a tree structure. It's also the most "efficient way to perform the first matching," as you say. > > ipfw add 1000 check-state > ipfw add 1001 skipto 10000 > ... > ipfw add 10000 allow ip from 10.0.0.1 to any ipfw add 10000 allow ip from 10.0.0.1 to any keep-state ?? :) > ipfw add 10000 deny ip from 10.0.0.2 to any > ipfw add 10000 deny ip from 10.0.0.3 to any > ipfw add 10000 allow ip from 10.0.0.4/28 to any > ... > ipfw add 10000 allow ip from 10.0.0.254 to any > > > There are some ways to solve the efficiency problem, but probably > > the simplest one is to to keep your code but put a "keep-state" > > option in each of the branch targets and in the index rule -- this > > way the matching will install a dynamic rule which can be then > > tested in O(1) time because this is supported by a hash table. --- Jon Simola | "In the near future - corporate networks Systems Administrator | reach out to the stars, electrons and light ABC Communications | flow throughout the universe." -- GITS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Jan 4 16:13:26 2001 From owner-freebsd-ipfw@FreeBSD.ORG Thu Jan 4 16:13:24 2001 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from newmail.netbistro.com (newmail.netbistro.com [204.239.167.35]) by hub.freebsd.org (Postfix) with SMTP id 04FE037B400 for ; Thu, 4 Jan 2001 16:13:23 -0800 (PST) Received: (qmail 26440 invoked by uid 1020); 5 Jan 2001 00:13:22 -0000 Date: Thu, 4 Jan 2001 16:13:22 -0800 (PST) From: Jon Simola X-Sender: jon@newmail.netbistro.com To: Luigi Rizzo Cc: ipfw@FreeBSD.ORG Subject: Re: Indexing IPFW rule In-Reply-To: <200101041434.f04EYC189940@iguana.aciri.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: jon@netbistro.com Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 4 Jan 2001, Luigi Rizzo wrote: > The idea in principle is ok, but your implementation is rather expensive > at runtime, as you have to scan the list of rules every time you > match a packet. I think this is too expensive in practice. > > Your code below seems to try and use the "next_rule_ptr" field which > i introduced some time ago to cache the jump target in skipto rules, > but this is not enough for your rules -- basically the 'if' > branch should be never taken. > > > + case IP_FW_F_INDEX: /* dst_ip */ > > + if ( f->next_rule_ptr ) > > + chain = f->next_rule_ptr ; > > + else > > + chain = lookup_index_rule(chain, dst_ip.s_addr) ; > > + if (! chain) goto dropit; > > + goto again ; Yep, that shows how inexperienced I am with the code :) I'll remove the if...else there. > Another problem in your code is that you hardwire the mask to > 24 bit in the code, this can be confusing. Yeah, a shortcut to getting the code working. I've got an idea how to fix that, just requires getting a little more familiar with the code. Thanks for the feedback. I'll keep working on this and re-emerge when I've got something a little more polished. --- Jon Simola | "In the near future - corporate networks Systems Administrator | reach out to the stars, electrons and light ABC Communications | flow throughout the universe." -- GITS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Jan 4 23:44:53 2001 From owner-freebsd-ipfw@FreeBSD.ORG Thu Jan 4 23:44:51 2001 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 1554837B400 for ; Thu, 4 Jan 2001 23:44:51 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f057ini96287; Thu, 4 Jan 2001 23:44:49 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200101050744.f057ini96287@iguana.aciri.org> Subject: Re: Indexing IPFW rule In-Reply-To: from Jon Simola at "Jan 4, 2001 4: 4:17 pm" To: jon@abccom.bc.ca (Jon Simola) Date: Thu, 4 Jan 2001 23:44:49 -0800 (PST) Cc: rizzo@aciri.org, ipfw@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: rizzo@iguana.aciri.org Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > on second thought... unless you find some more efficient way to > > perform the first matching, the "index" ipfw action seems completely ... > Yep, it's just that initial match that isn't pretty, and not simple to ... > jump into those rule blocks (gives me the wonderful side effect of traffic oh for traffic stats, you can replace the 'accept' rule with a "pipe N" action, where pipe N is configured as ipfw pipe N config mask src-ip 0xffffffff (or use different masks to aggregate more). > of skipto rules arranged in a tree structure. It's also the most "efficient > way to perform the first matching," as you say. i must disagree on the efficiency issue... your code still does a linear scan of the ruleset which is only partly (maybe a factor of 2-4) faster than letting ipfw do its own matches. A more efficient way would be to install the access list in the kernel in a way which can be accessed in O(1) time. A possible example would be a 256-bit string which tells you which hosts are enabled and which ones are not. You'd need a bit of parsing in the (userland) ipfw code to build the bitmap starting from a form like this: ipfw add match_dst_ip:0,1,25-31,44,45,37,96-100,\ 112,116,117,119,118,200-255 ip from any to 1.2.3.0/24 into the bitmap, and viceversa when printing out. The match would be on the portion of the address which is masked off, so you can accommodate smaller or larger sets easily. I'd definitely suggest this method, which looks straightforward to implement, and reasonably easy to understand (and you can still have traffic stats by replacing the action with a pipe!) Only catch is that you might need more room in the ipfw struct. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Fri Jan 5 1:57:46 2001 From owner-freebsd-ipfw@FreeBSD.ORG Fri Jan 5 01:57:44 2001 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from newmail.netbistro.com (newmail.netbistro.com [204.239.167.35]) by hub.freebsd.org (Postfix) with SMTP id D5AE637B400 for ; Fri, 5 Jan 2001 01:57:43 -0800 (PST) Received: (qmail 21935 invoked by uid 1020); 5 Jan 2001 09:57:43 -0000 Date: Fri, 5 Jan 2001 01:57:42 -0800 (PST) From: Jon Simola X-Sender: jon@newmail.netbistro.com To: Luigi Rizzo Cc: ipfw@FreeBSD.ORG Subject: Re: Indexing IPFW rule In-Reply-To: <200101050744.f057ini96287@iguana.aciri.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: jon@netbistro.com Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 4 Jan 2001, Luigi Rizzo wrote: > oh for traffic stats, you can replace the 'accept' rule with a "pipe N" > action, where pipe N is configured as > > ipfw pipe N config mask src-ip 0xffffffff Is there a way to zero the stats? I can't see a way to do that without ipfw delete (pipe rule) ipfw -f pipe flush ipfw pipe N config ipfw add (pipe rule) > A more efficient way would be to install the access list in the > kernel in a way which can be accessed in O(1) time. A possible > example would be a 256-bit string which tells you which hosts > are enabled and which ones are not. > I'd definitely suggest this method, which looks straightforward > to implement, and reasonably easy to understand (and you can > still have traffic stats by replacing the action with a pipe!) Yep, I'd have to agree with that. > Only catch is that you might need more room in the ipfw struct. Hmm... --- Jon Simola | "In the near future - corporate networks Systems Administrator | reach out to the stars, electrons and light ABC Communications | flow throughout the universe." -- GITS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Fri Jan 5 2: 3:48 2001 From owner-freebsd-ipfw@FreeBSD.ORG Fri Jan 5 02:03:47 2001 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 0A91E37B400 for ; Fri, 5 Jan 2001 02:03:47 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f05A3jo97252; Fri, 5 Jan 2001 02:03:45 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200101051003.f05A3jo97252@iguana.aciri.org> Subject: Re: Indexing IPFW rule In-Reply-To: from Jon Simola at "Jan 5, 2001 1:57:42 am" To: jon@abccom.bc.ca (Jon Simola) Date: Fri, 5 Jan 2001 02:03:45 -0800 (PST) Cc: rizzo@aciri.org, ipfw@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: rizzo@iguana.aciri.org Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > oh for traffic stats, you can replace the 'accept' rule with a "pipe N" ... > Is there a way to zero the stats? I can't see a way to do that without no, you'd need to implement a "pipe N zero" rule to zero the counters. > > Only catch is that you might need more room in the ipfw struct. > > Hmm... well, it is just a one line change in the struct definition! u_in32_t bitmap[8] ; cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Fri Jan 5 18:38:34 2001 From owner-freebsd-ipfw@FreeBSD.ORG Fri Jan 5 18:38:31 2001 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from proxy.outblaze.com (proxy.outblaze.com [202.77.223.120]) by hub.freebsd.org (Postfix) with SMTP id BAD1F37B400 for ; Fri, 5 Jan 2001 18:38:30 -0800 (PST) Received: (qmail 94205 invoked from network); 6 Jan 2001 02:38:29 -0000 Received: from unknown (HELO yusufg.portal2.com) (202.77.181.217) by proxy.outblaze.com with SMTP; 6 Jan 2001 02:38:29 -0000 Received: (qmail 19310 invoked by uid 500); 6 Jan 2001 02:42:29 -0000 Date: Sat, 6 Jan 2001 10:42:29 +0800 From: Yusuf Goolamabbas To: freebsd-ipfw@freebsd.org Subject: Using DUMMYNET on a filtering bridge Message-ID: <20010106104229.A19299@outblaze.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I seem to have a problem getting dummynet working on a filtering bridge running 4.2-stable as on Dec 6 Problem: I am trying to limit the total outbound bandwith from a certain machine. Prior to inserting the filtering bridge, it is directly connected to a switch port which is connected to the router and then to the leased line Now, I inserted a filtering bridge between the switch port and the machine. The connection looks like this FB ==> Filtering bridge switch-port -> fxp0 of FB machine with IP [A.B.C.D] -> fxp1 of FB I have bound an IP address to fxp0 of FB so I can login in there for remote and configure the box The following are the relevant options in my kernel config options NMBCLUSTERS=16384 options BRIDGE options IPFIREWALL options IPFIREWALL_VERBOSE options DUMMYNET options IPFIREWALL_DEFAULT_TO_ACCEPT I have the following in /etc/sysctl.conf net.link.ether.bridge_ipfw=1 net.link.ether.bridge=1 net.inet.ip.fw.dyn_max=10000 My rc.firewall looks like this ipfw add 100 pass all from any to any via lo0 ipfw add 200 deny all from any to 127.0.0.0/8 ipfw add 300 pass udp from 0.0.0.0 2054 to 0.0.0.0 ipfw add 400 pipe 1 ip from A.B.C.D to any in via fxp1 ipfw pipe 1 config bw 256 Kbit/s queue 30KB However, this does not seem to provide any shaping to the machine ipfw show does not show any packets/bytes counters incremented for rule 400. ipfw pipe show also shows up blank Is there some fundamental mistake I have made ? Regards, Yusuf -- Yusuf Goolamabbas yusufg@outblaze.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Sat Jan 6 5:57:56 2001 From owner-freebsd-ipfw@FreeBSD.ORG Sat Jan 6 05:57:53 2001 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 8E5C637B400 for ; Sat, 6 Jan 2001 05:57:53 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f06Dvno09349; Sat, 6 Jan 2001 05:57:49 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200101061357.f06Dvno09349@iguana.aciri.org> Subject: Re: Using DUMMYNET on a filtering bridge In-Reply-To: <20010106104229.A19299@outblaze.com> from Yusuf Goolamabbas at "Jan 6, 2001 10:42:29 am" To: yusufg@outblaze.com (Yusuf Goolamabbas) Date: Sat, 6 Jan 2001 05:57:49 -0800 (PST) Cc: freebsd-ipfw@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: rizzo@iguana.aciri.org Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As you noticed, you have misconfigured the firewall, as rule 400 does not match the traffic you want. Almost surely you need to remove the "in via fxp1" part, and also you need a second rule for the reverse traffic. cheers luigi > Hi, I seem to have a problem getting dummynet working on a filtering > bridge running 4.2-stable as on Dec 6 > > Problem: I am trying to limit the total outbound bandwith from a certain > machine. Prior to inserting the filtering bridge, it is directly > connected to a switch port which is connected to the router and then to > the leased line > > Now, I inserted a filtering bridge between the switch port and the > machine. The connection looks like this > > FB ==> Filtering bridge > > switch-port -> fxp0 of FB > machine with IP [A.B.C.D] -> fxp1 of FB > > I have bound an IP address to fxp0 of FB so I can login in there for > remote and configure the box > > The following are the relevant options in my kernel config > options NMBCLUSTERS=16384 > options BRIDGE > options IPFIREWALL > options IPFIREWALL_VERBOSE > options DUMMYNET > options IPFIREWALL_DEFAULT_TO_ACCEPT > > I have the following in /etc/sysctl.conf > net.link.ether.bridge_ipfw=1 > net.link.ether.bridge=1 > net.inet.ip.fw.dyn_max=10000 > > My rc.firewall looks like this > > ipfw add 100 pass all from any to any via lo0 > ipfw add 200 deny all from any to 127.0.0.0/8 > ipfw add 300 pass udp from 0.0.0.0 2054 to 0.0.0.0 > ipfw add 400 pipe 1 ip from A.B.C.D to any in via fxp1 > ipfw pipe 1 config bw 256 Kbit/s queue 30KB > > However, this does not seem to provide any shaping to the machine > > ipfw show does not show any packets/bytes counters incremented for rule > 400. ipfw pipe show also shows up blank > > Is there some fundamental mistake I have made ? > > Regards, Yusuf > > -- > Yusuf Goolamabbas > yusufg@outblaze.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Sat Jan 6 21:26:11 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from sm5.texas.rr.com (unknown [24.93.35.219]) by hub.freebsd.org (Postfix) with ESMTP id 5FAD437B400 for ; Sat, 6 Jan 2001 21:25:51 -0800 (PST) Received: from satx.rr.com (cs160144-62.satx.rr.com [24.160.144.62]) by sm5.texas.rr.com (8.11.0/8.11.1) with ESMTP id f076KHe12417 for ; Sun, 7 Jan 2001 00:20:17 -0600 Message-ID: <3A57FDDE.6B2D24C3@satx.rr.com> Date: Sat, 06 Jan 2001 23:25:50 -0600 From: blaz X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Subject: firewall/nat problems Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG greetings, I added the following to my kernel and rebuilt: options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options IPDIVERT then I added to /etc/rc.conf: gateway_enable="YES" firewall_enable="YES" natd_enable="YES" natd_interface="xl0" # my NIC connected to cable modem natd_flags="-dynamic" firewall_script="/etc/rc.firewall.new" then to my rc.firewall.new script is where I am getting confused.. not with the rules, but the variables I need to supply: #Define your variables # fwcmd="/sbin/ipfw" #leave as is if using ipfw oif="oifx" #set to outside interface name onwr="a.b.c.d/24" #set to outside network range oip="a.b.c.d" #set to outside ip address iif="ifx" #set to internal interface name inwr="x.y.z.x/24" #set to internal network range iip="x.y.z.x" #set to internal ip address ns1="e.f.g.h" #set to primary name server best if = oif #ntp="i.j.k.l" #set to ip of NTP server or leave as is below is what I supplied, and when I type to ping to local network I get TCP/IP denied.. its blocking the packets and I don't think its the rules, but the interface information. I will supply the rules at the end, in case it is -- I am going by an article I read on bsdtoday.com.. anyway here is what I supplied: fwcmd="/sbin/ipfw" #leave as is if using ipfw oif="xl0" #set to outside interface name onwr="255.255.255.0" #set to outside network range I am not sure about this.. oip="my ip" #set to outside ip address I use DHCP, but supplied current IP this has to be wrong iif="xl1" #set to internal interface name inwr="192.168.2/24" #set to internal network range iip="192.168.2.1" #set to internal ip address ns1="my name server" #set to primary name server best if = oif ntp="clock.isc.org" #set to ip of NTP server or leave as is I know I must have this screwerd up :) but here my rules in case its not: # Rules with descriptions # # # Force a flush of the current firewall rules before we reload $fwcmd -f flush # # Allow your loop back to work $fwcmd add allow all from any to any via lo0 # # Prevent spoofing of your loopback $fwcmd add deny log all from any to 127.0.0.0/8 # # Stop spoofing of your internal network range $fwcmd add deny log ip from $inwr to any in via $oif # # Stop spoofing from inside your private ip range $fwcmd add deny log ip from not $inwr to any in via $iif # # Stop private networks (RFC1918) from entering the outside interface. $fwcmd add deny log ip from 192.168.0.0/16 to any in via $oif $fwcmd add deny log ip from 172.16.0.0/12 to any in via $oif $fwcmd add deny log ip from 10.0.0.0/8 to any in via $oif $fwcmd add deny log ip from any to 192.168.0.0/16 in via $oif $fwcmd add deny log ip from any to 172.16.0.0/12 in via $oif $fwcmd add deny log ip from any to 10.0.0.0/8 in via $oif # # Stop draft-manning-dsua-01.txt nets on the outside interface $fwcmd add deny all from 0.0.0.0/8 to any in via $oif $fwcmd add deny all from 169.254.0.0/16 to any in via $oif $fwcmd add deny all from 192.0.2.0/24 to any in via $oif $fwcmd add deny all from 224.0.0.0/4 to any in via $oif $fwcmd add deny all from 240.0.0.0/4 to any in via $oif $fwcmd add deny all from any to 0.0.0.0/8 in via $oif $fwcmd add deny all from any to 169.254.0.0/16 in via $oif $fwcmd add deny all from any to 192.0.2.0/24 in via $oif $fwcmd add deny all from any to 224.0.0.0/4 in via $oif $fwcmd add deny all from any to 240.0.0.0/4 in via $oif # # Divert all packets through natd $fwcmd add divert natd all from any to any via $oif # # Allow all established connections to persist (setup required # for new connections). $fwcmd add allow tcp from any to any established # # Allow incomming requests to reach the following services: # To allow multiple services you may list them separated # by a coma, for example ...to $oip 22,25,110,80 setup $fwcmd add allow tcp from any to $oip 22 setup # # NOTE: you may have to change your client to passive or active mode # to get ftp to work once enabled, only ssh enabled by default. # 21:ftp # 22:ssh enabled by default # 23:telnet # 25:smtp # 110:pop # 143:imap # 80:http # 443:ssl # # Allow icmp packets for diagnostic purposes (ping traceroute) # you may wish to leave commented out. # $fwcmd add allow icmp from any to any # # Allow required ICMP $fwcmd add allow icmp from any to any icmptypes 3,4,11,12 # # Allow DNS traffic from internet to query your DNS (for reverse # lookups etc). $fwcmd add allow udp from any 53 to $ns1 53 # # Allow time update traffic # $fwcmd add allow udp from $ntp 123 to $oip 123 # # Checks packets against dynamic rule set below. $fwcmd add check-state # # Allow any traffic from firewall ip to any going out the # external interface $fwcmd add allow ip from $oip to any keep-state out via $oif # # Allow any traffic from local network to any passing through the # internal interface $fwcmd add allow ip from $inwr to any keep-state via $iif # # Deny everything else $fwcmd add 65435 deny log ip from any to any # ##################################################### # # End firewall script. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message