From owner-freebsd-ipfw@FreeBSD.ORG Sun May 16 16:16:25 2004 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 B162216A4CE for ; Sun, 16 May 2004 16:16:25 -0700 (PDT) Received: from bgezal.rise.tuwien.ac.at (bgezal.rise.tuwien.ac.at [128.130.59.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43D5D43D54 for ; Sun, 16 May 2004 16:16:25 -0700 (PDT) (envelope-from stefan@fafoe.narf.at) Received: from fafoe.narf.at (unknown [212.186.3.235]) by bgezal.rise.tuwien.ac.at (Postfix) with ESMTP id 0297820AB for ; Mon, 17 May 2004 01:16:23 +0200 (CEST) Received: from wombat.fafoe.narf.at (wombat.fafoe.narf.at [192.168.1.42]) by fafoe.narf.at (Postfix) with ESMTP id 6349540ED for ; Mon, 17 May 2004 01:16:15 +0200 (CEST) Received: by wombat.fafoe.narf.at (Postfix, from userid 1001) id 8B7C0388; Mon, 17 May 2004 01:16:11 +0200 (CEST) Date: Mon, 17 May 2004 01:16:11 +0200 From: Stefan Farfeleder To: ipfw@FreeBSD.org Message-ID: <20040516231608.GB653@wombat.fafoe.narf.at> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: Patch review 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: Sun, 16 May 2004 23:16:25 -0000 --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, any objections to me committing this patch? Cheers, Stefan Index: src/sbin/ipfw/ipfw2.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/home/ncvs/src/sbin/ipfw/ipfw2.c,v retrieving revision 1.48 diff -I.svn -u -r1.48 ipfw2.c --- src/sbin/ipfw/ipfw2.c 9 May 2004 01:53:31 -0000 1.48 +++ src/sbin/ipfw/ipfw2.c 16 May 2004 23:01:17 -0000 @@ -360,7 +360,7 @@ =20 bcopy (pll, &ret, sizeof(ret)); return ret; -}; +} =20 /* * conditionally runs the command. @@ -402,7 +402,7 @@ if (strlen(pt->s) =3D=3D i && !bcmp(string, pt->s, i)) return pt->x; return -1; -}; +} =20 /** * match_value takes a table and a value, returns the string associated --IS0zKkzwUGydFO0o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAp/Y3MZ+LKIvv0V8RApP5AJ4iOyrGlsLlk3s4blDBNBYwxGCBeACfVc/w hG8XcaTlGu62jyS0g0mHJ6E= =AQ/W -----END PGP SIGNATURE----- --IS0zKkzwUGydFO0o-- From owner-freebsd-ipfw@FreeBSD.ORG Sun May 16 23:51:19 2004 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 7109D16A4CE; Sun, 16 May 2004 23:51:19 -0700 (PDT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D30743D48; Sun, 16 May 2004 23:51:18 -0700 (PDT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i4H6uUE2041471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 May 2004 09:56:32 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i4H6pFvT015824; Mon, 17 May 2004 09:51:15 +0300 (EEST) (envelope-from ru) Date: Mon, 17 May 2004 09:51:15 +0300 From: Ruslan Ermilov To: Stefan Farfeleder Message-ID: <20040517065115.GA15785@ip.net.ua> References: <20040516231608.GB653@wombat.fafoe.narf.at> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline In-Reply-To: <20040516231608.GB653@wombat.fafoe.narf.at> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: ipfw@freebsd.org Subject: Re: Patch review 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, 17 May 2004 06:51:19 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 17, 2004 at 01:16:11AM +0200, Stefan Farfeleder wrote: > Hi, >=20 > any objections to me committing this patch? >=20 Please go ahead. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAqGDjUkv4P6juNwoRAgivAKCD7mLRaH74dMJeH6MKpEd2MpVdYwCcCz7M Rrdske75i/K0L6cu6ubcpoc= =9G9W -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From owner-freebsd-ipfw@FreeBSD.ORG Mon May 17 06:15:31 2004 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 9DF3116A4CE; Mon, 17 May 2004 06:15:31 -0700 (PDT) Received: from mta6.adelphia.net (mta6.adelphia.net [68.168.78.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87AB043D1D; Mon, 17 May 2004 06:15:29 -0700 (PDT) (envelope-from Barbish3@adelphia.net) Received: from barbish ([67.20.101.71]) by mta13.adelphia.net (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with SMTP id <20040517131226.UXTO13425.mta13.adelphia.net@barbish>; Mon, 17 May 2004 09:12:26 -0400 From: "JJB" To: , "Christian Hiris" <4711@chello.at> Date: Mon, 17 May 2004 09:12:24 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200405171432.38987.4711@chello.at> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 cc: "Freebsd-Ipfw@Freebsd. Org" cc: Anthony Philipp cc: Micheal Patterson Subject: RE: natd -redirect_port X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Barbish3@adelphia.net List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2004 13:15:31 -0000 Now wouldn't it just be better all the way around to create the IPFW loadable module that is distributed with the system, with the correct divert and logging options so it's not an mandatory requirement to compile the kernel. Why make this so difficult for the normal user?. Simpler and easier is always better than more complicated. Look at it this way, A firewall without logging is useless, and the majority of people who use IPFW have an lan behind their IPFW firewall, so the sensible thing to do is distribute the IPFW loadable module configured in an manner to address the needs of the largest user group. As it's distributed now the loadable module is all most completely useless so why even have one? My personal option is the IPFW loadable module is not configured correctly and needs to be corrected. -----Original Message----- From: Christian Hiris [mailto:4711@chello.at] Sent: Monday, May 17, 2004 8:32 AM To: freebsd-questions@freebsd.org; Barbish3@adelphia.net Cc: Micheal Patterson; Anthony Philipp Subject: Re: natd -redirect_port On Saturday 15 May 2004 18:56, JJB wrote: > You are wrong also. The boot time message that displays about the > ipfw module being loaded is incorrect. I filed an PR on that in 5.1 > and was told by developers that message is misleading, that the > module is fully enabled with nat and logging, so I tested and indeed > nat and logging is really in the loadable module. It's my > understanding the boot time message that displays about the ipfw > module being loaded that says everything is disabled will be > corrected in 5.3. What is in the 5.2.1 ipfw module I do not know. > My advice is to test ipfw module before adding ipfw option > statements to kernel. That's why the 5.x versions are development > versions, things change all the time until that get corrected before > be coming stable releases. This is all new because ipfw2 replaced > ipfw at the 5.1 version I believe. Just think about it, why have an > loadable module if all the options are turned off, it makes the > module useless. Ipfilter's loadable module is full function with > nat and logging why should the ipfw module be any different? It's > just that stupid message that has been misleading users all this > time just like it did to me. If nat and logging is missing from the > ipfw loadable module in 5.2.1 then submit another PR to remind then > it needs to be corrected. Nat and logging are the most used options > of ipfw, it's just plain stupid not to have then included in the > standard module. If a user wants ipfw to issue the correct initial divert message, it's still required to compile ipfw into the kernel. This means 'option IPFIREWALL' is required as stated in the natd manual. Actually on 5.2-current the ipfw module doesn't know if the kernel has been compiled with ipdivert proto. This causes the wrong 'divert disabled' initial message. I will file a PR on the wrong initial divert message issue tomorrow. If the ipdivert proto capability could be retrieved via divcb sysctl or any other mechanism, it might become possible that the ipfw kld could issue the correct divert message. Disabling of the divert message in case the ipfw has been compiled as kld could be a simpler solution. > > -----Original Message----- > From: Micheal Patterson [mailto:micheal@tsgincorporated.com] > Sent: Saturday, May 15, 2004 11:38 AM > To: Barbish3@adelphia.net; Christian Hiris; > freebsd-questions@freebsd.org > Cc: Anthony Philipp > Subject: Re: natd -redirect_port > > > ----- Original Message ----- > From: "JJB" > To: "Christian Hiris" <4711@chello.at>; > > Cc: "Anthony Philipp" > Sent: Saturday, May 15, 2004 8:05 AM > Subject: RE: natd -redirect_port > > > You are wrong, you do not have to compile ipfirewall kernel > > options > > > into the kernel. > > IPFW is delivered as an bootable module. > > You need this in rc.conf to enable ipfw, it will auto load the > > bootable module. > > > > # Required For IPFW kernel firewall support > > firewall_enable="YES" # Start daemon > > firewall_script="/etc/ipfw.rules" # run my custom rules > > firewall_logging="YES" # Enable events logging > > > > natd_enable="YES" # Enable IPFW nat function > > natd_interface="rl0" > > natd_flags="-dynamic -m -u -f /etc/natd.conf" > > You're right, you don't have to recompile to use ipfw, however, > since there > is no divert module, the kernel will still need to be recompiled to > enable > divert. In order for the OP to do what they're wanting to do they > will still > need to recompile kernel and restart the system. > > -- > > Micheal Patterson > TSG Network Administration > 405-917-0600 > > Confidentiality Notice: This e-mail message, including any > attachments, is > for the sole use of the intended recipient(s) and may contain > confidential > and privileged information. Any unauthorized review, use, disclosure > or > distribution is prohibited. If you are not the intended recipient, > please > contact the sender by reply e-mail and destroy all copies of the > original > message. > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "freebsd-questions-unsubscribe@freebsd.org" -- Christian Hiris <4711@chello.at> | OpenPGP KeyID 0x941B6B0B OpenPGP-Key at hkp://wwwkeys.eu.pgp.net and http://pgp.mit.edu From owner-freebsd-ipfw@FreeBSD.ORG Mon May 17 06:42:10 2004 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 90A5A16A4CE for ; Mon, 17 May 2004 06:42:10 -0700 (PDT) Received: from bagira.apex.dp.ua (bagira.apex.dp.ua [195.24.128.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 877E243D49 for ; Mon, 17 May 2004 06:42:08 -0700 (PDT) (envelope-from trooper+freebsd+ipfw@email.dp.ua) Received: from i100.apex.dp.ua ([192.168.2.100] helo=email.dp.ua) by volcano.apex.dp.ua with esmtp (TLSv1:AES256-SHA:256) (Exim 4.12) id 1BPiNa-000NbA-00 for ipfw@freebsd.org; Mon, 17 May 2004 16:42:06 +0300 Message-ID: <40A8C12D.5040906@email.dp.ua> Date: Mon, 17 May 2004 16:42:05 +0300 From: Dmitry Sergienko Organization: Trifle Co., Ltd. User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: ipfw@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1BPiNa-000NbA-00*6OzTpWjb0Bs* Subject: ipfw prefix-list support request 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, 17 May 2004 13:42:10 -0000 Hi! I'm thinking about external prefix-lists in ipfw. This is like prefix-lists in Cisco IOS or tables in OpenBSD pf. In my opinion it will be very convenient to do the following: # use prefix-list ipfw add 100 allow ip from prefix-list goodcustomers to any // add prefixes to prefix-list #ipfw prefix-list goodcustomers add 10.0.0.0/24 ipfw prefix-list goodcustomers add 10.0.1.0/30 ipfw prefix-list goodcustomers add 10.0.1.5 // list prefixes in prefix-list #ipfw prefix-list goodcustomers list 10.0.0.0/24 (5 matches) 10.0.1.0/24 // clear counters in prefix-list #ipfw prefix-list goodcustomers zero // show all available prefix-lists #ipfw prefix-list show good-customers // delete items from prefix-list #ipfw prefix-list goodcustomers delete 10.0.0.0/24 // delete all items from prefix-list #ipfw prefix-list goodcustomers flush The main advantage is to maintain list of prefixes separately from rule, without tweaking the rule. Current syntax in ipfw2 doesn't allow to do this (or have I missed something?). Please tell your opinion about this feature, is it really will be useful not only for me? If so, we will try to implement this. -- Best wishes, Dmitry Sergienko (SDA104-RIPE) Trifle Co., Ltd. From owner-freebsd-ipfw@FreeBSD.ORG Mon May 17 07:17:36 2004 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 7A2BB16A4CE for ; Mon, 17 May 2004 07:17:36 -0700 (PDT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73DE143D49 for ; Mon, 17 May 2004 07:17:35 -0700 (PDT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 876381FFDD3; Mon, 17 May 2004 16:17:33 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id AF1301FFDC1; Mon, 17 May 2004 16:17:31 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id EBA3F154E5; Mon, 17 May 2004 14:14:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id E0B20154E2; Mon, 17 May 2004 14:14:16 +0000 (UTC) Date: Mon, 17 May 2004 14:14:16 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Dmitry Sergienko In-Reply-To: <40A8C12D.5040906@email.dp.ua> Message-ID: References: <40A8C12D.5040906@email.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: ipfw@freebsd.org Subject: Re: ipfw prefix-list support request 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, 17 May 2004 14:17:36 -0000 On Mon, 17 May 2004, Dmitry Sergienko wrote: > I'm thinking about external prefix-lists in ipfw. This is like > prefix-lists in Cisco IOS or tables in OpenBSD pf. > In my opinion it will be very convenient to do the following: also sound like chains ? ... > The main advantage is to maintain list of prefixes separately from > rule, without tweaking the rule. > Current syntax in ipfw2 doesn't allow to do this (or have I missed > something?). > > Please tell your opinion about this feature, is it really will be useful > not only for me? If so, we will try to implement this. use ipfw -p p.ex. with m4 you can do define(`goodcustomers',`{ 10.0.0.0/8 or 192.168.0.0/24 }')dnl add permit ip from goodcustomers to goodcustomers or s.th. like that. Of course you do not need -p /usr/bin/m4 if you simply want to write add permit ip from { 10.0.0.0/8 or 192.168.0.0/24 } to { 10.0.0.0/8 or 192.168.0.0/24 } You might want to use perl or s.th. else to build up the list if you prefer Cisco config style but that's really a matter of the preprocessor then. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-ipfw@FreeBSD.ORG Mon May 17 07:53:22 2004 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 E21E316A4D2 for ; Mon, 17 May 2004 07:53:22 -0700 (PDT) Received: from bagira.apex.dp.ua (bagira.apex.dp.ua [195.24.128.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id B483D43D39 for ; Mon, 17 May 2004 07:53:21 -0700 (PDT) (envelope-from trooper+freebsd+ipfw@email.dp.ua) Received: from i100.apex.dp.ua ([192.168.2.100] helo=email.dp.ua) by volcano.apex.dp.ua with esmtp (TLSv1:AES256-SHA:256) (Exim 4.12) id 1BPjUW-0003hU-00; Mon, 17 May 2004 17:53:20 +0300 Message-ID: <40A8D1DF.8010605@email.dp.ua> Date: Mon, 17 May 2004 17:53:19 +0300 From: Dmitry Sergienko Organization: Trifle Co., Ltd. User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <40A8C12D.5040906@email.dp.ua> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1BPjUW-0003hU-00*55umL.1l7WY* cc: ipfw@freebsd.org Subject: Re: ipfw prefix-list support request 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, 17 May 2004 14:53:23 -0000 Hi! Bjoern A. Zeeb wrote: >>The main advantage is to maintain list of prefixes separately from >>rule, without tweaking the rule. >>Current syntax in ipfw2 doesn't allow to do this (or have I missed >>something?). >> >>Please tell your opinion about this feature, is it really will be useful >>not only for me? If so, we will try to implement this. > > > use ipfw -p > > p.ex. with m4 you can do > > define(`goodcustomers',`{ 10.0.0.0/8 or 192.168.0.0/24 }')dnl > add permit ip from goodcustomers to goodcustomers > > or s.th. like that. Of course you do not need -p /usr/bin/m4 > if you simply want to write > > add permit ip from { 10.0.0.0/8 or 192.168.0.0/24 } to { 10.0.0.0/8 or 192.168.0.0/24 } > > You might want to use perl or s.th. else to build up the list > if you prefer Cisco config style but that's really a matter > of the preprocessor then. Thank you for replying. It is not a problem to generate rules with help of any text processing tool. But it will be just like a macros. The problem is to change lists of address without modifying existing rule, dynamically. If I need to change list of addresses I have to kill existing rule and insert another with the same number. This is unconvenient. If I generate list of ipfw rules I need to reload all rules which is unconvenient also. The next. Maybe I'm wrong, but as far as I saw sbin/ipfw2.c OR blocks are generated as list of items to be checked by kernel. Hash will be more effective if we have a lot of prefixes. Also I can't see stats by exact prefix in OR blocks, only by whole rule. -- Best wishes, Dmitry Sergienko (SDA104-RIPE) Trifle Co., Ltd. From owner-freebsd-ipfw@FreeBSD.ORG Mon May 17 08:11:21 2004 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 B370316A4CE for ; Mon, 17 May 2004 08:11:21 -0700 (PDT) Received: from chello080110061116.502.15.vie.surfer.at (chello080110061116.502.15.vie.surfer.at [80.110.61.116]) by mx1.FreeBSD.org (Postfix) with SMTP id 3203843D46 for ; Mon, 17 May 2004 08:11:19 -0700 (PDT) (envelope-from 4711@chello.at) Received: (qmail 21826 invoked from network); 17 May 2004 15:11:14 -0000 Received: from matrix010.matrix.net (192.168.123.10) by ns.matrix.net with SMTP; 17 May 2004 15:11:14 -0000 From: Christian Hiris <4711@chello.at> To: freebsd-ipfw@freebsd.org, Barbish3@adelphia.net Date: Mon, 17 May 2004 17:10:44 +0200 User-Agent: KMail/1.6.2 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_SYNqA32rKbjgWDT"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405171711.14330.4711@chello.at> cc: JJB Subject: Re: natd -redirect_port 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, 17 May 2004 15:11:21 -0000 --Boundary-02=_SYNqA32rKbjgWDT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 17 May 2004 15:12, JJB wrote: > Now wouldn't it just be better all the way around to create the IPFW > loadable module that is distributed with the system, with the > correct divert and logging options so it's not an mandatory > requirement to compile the kernel. It wold be fine to have a ipdivert.ko that could be loaded on demand of=20 ipfw.ko or via /etc/rc.d/natd. I think the main reason why we have no=20 ipdivert.ko around is that the ipdivert code toches severeal kernel sources= =2E=20 As I understand it, the divert proto is not just a piece of code that could= =20 simply pluged in and out (for now). I have no problem with logging diabled by default, as enabling needs only o= ne=20 line in rc.conf. =20 ps: please dont top-post and use some indentation character for quoting of = old=20 message text. This makes reading much easier. =20 > Why make this so difficult for=20 > the normal user?. Simpler and easier is always better than more > complicated. Look at it this way, A firewall without logging is > useless, and the majority of people who use IPFW have an lan behind > their IPFW firewall, so the sensible thing to do is distribute the > IPFW loadable module configured in an manner to address the needs of > the largest user group. As it's distributed now the loadable module > is all most completely useless so why even have one? > > My personal option is the IPFW loadable module is not configured > correctly and needs to be corrected. > > -----Original Message----- > From: Christian Hiris [mailto:4711@chello.at] > Sent: Monday, May 17, 2004 8:32 AM > To: freebsd-questions@freebsd.org; Barbish3@adelphia.net > Cc: Micheal Patterson; Anthony Philipp > Subject: Re: natd -redirect_port > > On Saturday 15 May 2004 18:56, JJB wrote: > > You are wrong also. The boot time message that displays about the > > ipfw module being loaded is incorrect. I filed an PR on that in > > 5.1 > > > and was told by developers that message is misleading, that the > > module is fully enabled with nat and logging, so I tested and > > indeed > > > nat and logging is really in the loadable module. It's my > > understanding the boot time message that displays about the ipfw > > module being loaded that says everything is disabled will be > > corrected in 5.3. What is in the 5.2.1 ipfw module I do not know. > > My advice is to test ipfw module before adding ipfw option > > statements to kernel. That's why the 5.x versions are development > > versions, things change all the time until that get corrected > > before > > > be coming stable releases. This is all new because ipfw2 replaced > > ipfw at the 5.1 version I believe. Just think about it, why have > > an > > > loadable module if all the options are turned off, it makes the > > module useless. Ipfilter's loadable module is full function with > > nat and logging why should the ipfw module be any different? It's > > just that stupid message that has been misleading users all this > > time just like it did to me. If nat and logging is missing from > > the > > > ipfw loadable module in 5.2.1 then submit another PR to remind > > then > > > it needs to be corrected. Nat and logging are the most used > > options > > > of ipfw, it's just plain stupid not to have then included in the > > standard module. > > If a user wants ipfw to issue the correct initial divert message, > it's still > required to compile ipfw into the kernel. This means 'option > IPFIREWALL' is > required as stated in the natd manual. > > Actually on 5.2-current the ipfw module doesn't know if the kernel > has been > compiled with ipdivert proto. This causes the wrong 'divert > disabled' initial > message. > > I will file a PR on the wrong initial divert message issue tomorrow. > If the > ipdivert proto capability could be retrieved via divcb sysctl or any > other > mechanism, it might become possible that the ipfw kld could issue > the correct > divert message. > Disabling of the divert message in case the ipfw has been compiled > as kld > could be a simpler solution. > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "freebsd-questions-unsubscribe@freebsd.org" =2D-=20 Christian Hiris <4711@chello.at> | OpenPGP KeyID 0x941B6B0B=20 OpenPGP-Key at hkp://wwwkeys.eu.pgp.net and http://pgp.mit.edu --Boundary-02=_SYNqA32rKbjgWDT Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAqNYScyi/EZQbawsRArGyAJ93XjmWxnbly22KcwkelkyNQRT3xQCfYScP S3BEHkrW43J+cdliBzWMrEs= =wYOr -----END PGP SIGNATURE----- --Boundary-02=_SYNqA32rKbjgWDT-- From owner-freebsd-ipfw@FreeBSD.ORG Mon May 17 11:02:02 2004 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 F408416A4CE for ; Mon, 17 May 2004 11:02:01 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B512543D48 for ; Mon, 17 May 2004 11:02:01 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i4HI213M097976 for ; Mon, 17 May 2004 11:02:01 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i4HI20Ev097970 for ipfw@freebsd.org; Mon, 17 May 2004 11:02:01 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 17 May 2004 11:02:01 -0700 (PDT) Message-Id: <200405171802.i4HI20Ev097970@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: ipfw@FreeBSD.org Subject: Current problem reports assigned to you 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, 17 May 2004 18:02:02 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/12/27] kern/46557 ipfw ipfw pipe show fails with lots of queues o [2003/04/22] kern/51274 ipfw ipfw2 create dynamic rules with parent nu f [2003/04/24] kern/51341 ipfw ipfw rule 'deny icmp from any to any icmp o [2004/03/03] misc/63724 ipfw IPFW2 Queues dont t work o [2004/03/13] kern/64240 ipfw IPFW tee terminates rule processing 5 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- a [2001/04/13] kern/26534 ipfw Add an option to ipfw to log gid/uid of w o [2002/12/07] kern/46080 ipfw [PATCH] logamount in ipfw2 does not defau o [2002/12/10] kern/46159 ipfw ipfw dynamic rules lifetime feature o [2002/12/27] kern/46564 ipfw IPFilter and IPFW processing order is not o [2003/02/11] kern/48172 ipfw ipfw does not log size and flags o [2003/03/10] kern/49086 ipfw [patch] Make ipfw2 log to different syslo o [2003/03/12] bin/49959 ipfw ipfw tee port rule skips parsing next rul o [2003/04/09] bin/50749 ipfw ipfw2 incorrectly parses ports and port r o [2003/08/25] kern/55984 ipfw [patch] time based firewalling support fo o [2003/12/29] kern/60719 ipfw ipfw: Headerless fragments generate cryp o [2004/01/12] kern/61259 ipfw [patch] make "ipfw tee" work as intended o [2004/02/09] kern/62598 ipfw no logging on ipfw loadable module o [2004/03/08] kern/63961 ipfw ipfw2 uid matching doesn't work correctly 13 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon May 17 11:33:01 2004 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 212F916A4CE for ; Mon, 17 May 2004 11:33:01 -0700 (PDT) Received: from smtp.wan.no (smtp.wan.no [80.86.128.91]) by mx1.FreeBSD.org (Postfix) with SMTP id E75B643D41 for ; Mon, 17 May 2004 11:32:59 -0700 (PDT) (envelope-from sten.daniel.sorsdal@wan.no) Received: (qmail 30930 invoked from network); 17 May 2004 18:49:00 -0000 Received: from unknown (HELO exchange.wan.no) (10.30.1.52) by smtp.wan.no with SMTP; 17 May 2004 18:49:00 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Mon, 17 May 2004 20:32:56 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ipfw prefix-list support request Thread-Index: AcQ8FN3PCZ+nP6XUTVuzDLNGa5KHWQAKDwwg From: =?iso-8859-1?Q?Sten_Daniel_S=F8rsdal?= To: "Dmitry Sergienko" , Subject: RE: ipfw prefix-list support request 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, 17 May 2004 18:33:01 -0000 >=20 > Hi! >=20 > I'm thinking about external prefix-lists in ipfw. This is like > prefix-lists in Cisco IOS or tables in OpenBSD pf. > In my opinion it will be very convenient to do the following: > ... >=20 > Please tell your opinion about this feature, is it really=20 > will be useful > not only for me? If so, we will try to implement this. >=20 Sounds great to me! _// Sten Daniel S=F8rsdal From owner-freebsd-ipfw@FreeBSD.ORG Mon May 17 15:11:00 2004 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 0935B16A4CE for ; Mon, 17 May 2004 15:11:00 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B33243D1D for ; Mon, 17 May 2004 15:10:59 -0700 (PDT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i4HMApgd065433; Mon, 17 May 2004 15:10:51 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i4HMAoML065432; Mon, 17 May 2004 15:10:50 -0700 (PDT) (envelope-from rizzo) Date: Mon, 17 May 2004 15:10:50 -0700 From: Luigi Rizzo To: Dmitry Sergienko Message-ID: <20040517151050.B63591@xorpc.icir.org> References: <40A8C12D.5040906@email.dp.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <40A8C12D.5040906@email.dp.ua>;04:42:05PM +0300 cc: ipfw@freebsd.org Subject: Re: ipfw prefix-list support request 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, 17 May 2004 22:11:00 -0000 On Mon, May 17, 2004 at 04:42:05PM +0300, Dmitry Sergienko wrote: > Hi! > > I'm thinking about external prefix-lists in ipfw. This is like I think everybody agrees that it would be great to have in ipfw2 named objects such as list of ports, prefixes, etc that one can dynamically modify without having to rewrite rules. The issues are: + (minor but important) find a decent syntax -- your example ipfw add 100 allow ip from prefix-list goodcustomers to any is ambiguous as prefix-list could be a hostname and goodcustomers a service name. Given that this is ipfw2, you can use ipfw2 syntax and define a new keyword 'src-prefix-list' to be used as ipfw add 100 allow src-prefix-list goodcustomers ... + define the semantics clearly -- do you want longest prefix match, or just any match (it does make a difference in the management of counters); + implement the list efficiently -- to avoid huge search times, one implement the list as some kind of compressed trie. HOWEVER, if the list is short (some 10 entries) a linear search is probably a lot more efficient, so your code should cover both cases. + remember that ipfw(2) accepts one line at a time -- so there will be times when the configuration is inconsistent e.g. you might have rules pointing to a non-existing list. Make sure the handling of these cases is not terribly expensive. The 'or block' { 10.0.0.0/8 or 192.168.0.0/24 } and the 'address set' 10.0.2.0/24{3,80,118,128-191,224-231} are surrogates that cover simple uses of the prefix list, but certainly not all of them. I think for the code you could try to borrow something from pf. Post patches when you have them. cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Mon May 17 20:24:08 2004 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 C74DB16A4CE for ; Mon, 17 May 2004 20:24:08 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBD1343D58 for ; Mon, 17 May 2004 20:24:01 -0700 (PDT) (envelope-from max@love2party.net) Received: from [212.227.126.162] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BPvCy-0001cr-00 for freebsd-ipfw@freebsd.org; Tue, 18 May 2004 05:24:00 +0200 Received: from [216.58.85.218] (helo=[10.0.0.49]) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1BPvCx-0000Fo-00 for freebsd-ipfw@freebsd.org; Tue, 18 May 2004 05:24:00 +0200 From: Max Laier To: freebsd-ipfw@freebsd.org Date: Tue, 18 May 2004 05:25:33 +0200 User-Agent: KMail/1.6.2 References: <40A8C12D.5040906@email.dp.ua> <20040517151050.B63591@xorpc.icir.org> In-Reply-To: <20040517151050.B63591@xorpc.icir.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405180525.36273.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e28873fbe4dbe612ce62ab869898ff08 Subject: Re: ipfw prefix-list support request 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: Tue, 18 May 2004 03:24:09 -0000 On Tuesday 18 May 2004 00:10, Luigi Rizzo wrote: > I think for the code you could try to borrow something from pf. I'll try to describe a bit how it is handled in pf, to give you some more hints in case you are going to look at the code ... > On Mon, May 17, 2004 at 04:42:05PM +0300, Dmitry Sergienko wrote: > > Hi! > > > > I'm thinking about external prefix-lists in ipfw. This is like > > I think everybody agrees that it would be great to have in ipfw2 > named objects such as list of ports, prefixes, etc that one can > dynamically modify without having to rewrite rules. > > The issues are: > + (minor but important) find a decent syntax -- your example > > ipfw add 100 allow ip from prefix-list goodcustomers to any > > is ambiguous as prefix-list could be a hostname and goodcustomers > a service name. Given that this is ipfw2, you can use ipfw2 syntax > and define a new keyword 'src-prefix-list' to be used as > > ipfw add 100 allow src-prefix-list goodcustomers ... pf defines tables: table [initial ips] and uses "<" and ">" to enclose a table in a filter rule. Like: pass on xl0 from to any This might be problematic as ipfw uses shell scripts to feed the rules into ipfw, so "<>" might have special meaning ... > + define the semantics clearly -- do you want longest prefix match, > or just any match (it does make a difference in the management of > counters); > > + implement the list efficiently -- to avoid huge search times, one > implement the list as some kind of compressed trie. HOWEVER, if the > list is short (some 10 entries) a linear search is probably a lot > more efficient, so your code should cover both cases. pf uses the existing radix-tree implementation for the tables. This provides lookups in O(32) for IPv4 and O(128) for IPv6 which means it's a constant time lookup. Unfortunately, the radix code has some locking requirements that add overhead but it's sure worth looking at. Using the radix-tree here, also decides how to deal with the matching: special case wins over common case, making it possible to say something like: Allow 10/8 but not 10.0.5/24 ... it's really neat. Look in pf.conf(5) and the pf faq on www.openbsd.org for more examples and explaination. > + remember that ipfw(2) accepts one line at a time -- so there will be > times when the configuration is inconsistent e.g. you might have rules > pointing to a non-existing list. Make sure the handling of these cases > is not terribly expensive. I have no clue how to address this, but I find it a rather gross way of dealing with a ruleSET ... Final note: The pf code to handle this resides in sys/contrib/pf/net/ pf_table.c and is not very easy to read. It's supposably more easy to start with a new implementation starting from the radix code and taking the pf behaviour as reference/inspiration. I hope that helps. -- Best regards, | mlaier@freebsd.org Max Laier | ICQ #67774661 http://pf4freebsd.love2party.net/ | mlaier@EFnet From owner-freebsd-ipfw@FreeBSD.ORG Tue May 18 00:07:11 2004 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 BD58416A4CE for ; Tue, 18 May 2004 00:07:11 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C770543D1D for ; Tue, 18 May 2004 00:07:10 -0700 (PDT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i4I777gd096534; Tue, 18 May 2004 00:07:07 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i4I7775c096533; Tue, 18 May 2004 00:07:07 -0700 (PDT) (envelope-from rizzo) Date: Tue, 18 May 2004 00:07:06 -0700 From: Luigi Rizzo To: Max Laier Message-ID: <20040518000706.A96220@xorpc.icir.org> References: <40A8C12D.5040906@email.dp.ua> <20040517151050.B63591@xorpc.icir.org> <200405180525.36273.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200405180525.36273.max@love2party.net>; from max@love2party.net on Tue, May 18, 2004 at 05:25:33AM +0200 cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw prefix-list support request 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: Tue, 18 May 2004 07:07:11 -0000 On Tue, May 18, 2004 at 05:25:33AM +0200, Max Laier wrote: ... > I'll try to describe a bit how it is handled in pf, to give you some more > hints in case you are going to look at the code ... good, thanks. > pf uses the existing radix-tree implementation for the tables. This provides > lookups in O(32) for IPv4 and O(128) for IPv6 which means it's a constant > time lookup. Unfortunately, the radix code has some locking requirements that > add overhead but it's sure worth looking at. well, good luck :) it's not just the locking requirements, it's the space used for each entry and the very complicated API to use it that scares me -- basically requiring a lot of extra work to format arguments. If anything, a good output from this kind of project would be a reimplementation of a forwarding table... > > + remember that ipfw(2) accepts one line at a time -- so there will be > > times when the configuration is inconsistent e.g. you might have rules > > pointing to a non-existing list. Make sure the handling of these cases > > is not terribly expensive. > > I have no clue how to address this, but I find it a rather gross way of > dealing with a ruleSET ... well this was for backward compatibility. The way ipfw2/dummynet handle this is the same way in whihc one should handle pluggable hardware -- invalidate pointers on departures, flag arrivals so that the code can (lazily) try to update an invalid reference after an arrival. A generation-id of some kind would make the mechanism very simple. cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Fri May 21 17:23:10 2004 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 316CB16A4CE for ; Fri, 21 May 2004 17:23:10 -0700 (PDT) Received: from gateway.posi.net (adsl-63-201-93-169.dsl.snfc21.pacbell.net [63.201.93.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EC0343D58 for ; Fri, 21 May 2004 17:23:09 -0700 (PDT) (envelope-from kbyanc@posi.net) Received: from localhost (localhost [127.0.0.1]) by gateway.posi.net (Postfix) with ESMTP id 9972C6A046F; Fri, 21 May 2004 17:23:35 -0700 (PDT) Date: Fri, 21 May 2004 17:23:34 -0700 (PDT) From: Kelly Yancey To: =?iso-8859-1?Q?Sten_Daniel_S=F8rsdal?= In-Reply-To: Message-ID: <20040521171452.W7124@gateway.posi.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE cc: ipfw@freebsd.org cc: Dmitry Sergienko Subject: RE: ipfw prefix-list support request 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: Sat, 22 May 2004 00:23:10 -0000 On Mon, 17 May 2004, [iso-8859-1] Sten Daniel S=F8rsdal wrote: > > > > Hi! > > > > I'm thinking about external prefix-lists in ipfw. This is like > > prefix-lists in Cisco IOS or tables in OpenBSD pf. > > In my opinion it will be very convenient to do the following: > > > ... > > > > Please tell your opinion about this feature, is it really > > will be useful > > not only for me? If so, we will try to implement this. > > > > Sounds great to me! > I had implemented something similar to this some time back (before pf gre= w tables); the syntax isn't quite as clean, though: # ipfw add 50 allow ip from class[10] to any # ipfw add 60 allow ip from any to class[10] # ipfw -c show 00050 0 0 allow ip from class[10] to any 00060 0 0 allow ip from any to class[10] ... # ipfw class 10 add 00:02:b3:90:6a:31 216.69.69.112 # ipfw class 10 add 11:22:33:44:55:66 1.2.3.4 # ipfw class 10 # ipfw class 10 show 0 0 0 0 11:22:33:44:55:66 1.2.3.4 0 0 0 0 00:02:b3:90:6a:31 216.69.69.1= 12 ... transfer a bunch of files... # ipfw show -c 00050 788079 1119439715 allow ip from class[10] to any 00060 324895 16913392 allow ip from any to class[10] ... # ipfw class 10 show 0 0 0 0 11:22:33:44:55:66 1.2.3.4 788079 1119439715 324895 16913392 00:02:b3:90:6a:31 216.69.69.1= 12 In my case, I needed to primarilly match MAC addresses; the IP address matching is secondary. As it is, one can specify only a MAC address when t= he entry is added to the class and packets are matched against that. If you specify both the MAC and IP, both are matched. I have always intended to m= ake this more generic so that all (sensible) combinations of IPv4, IPv6, and MA= C addresses are supported as ipfw2 now has support for IPv4 and MAC addresses (with IPv6 on the horizon). Unfortunately, the implementation is against 4.7, so it would take some updating before it would be useful to anyone else. As you can see, it does not support subnet masks, though, whereas pf's table implementation does. = The entries are stored in a hash table. If this could be a useful starting poi= nt, I could supply patches to anyone working on it. Kelly P.S. I use ipfw -p cpp to assign names to the numeric classes in my rulesets. -- Kelly Yancey - kbyanc@{posi.net,FreeBSD.org} - kelly@nttmcl.com FreeBSD, The Power To Serve: http://www.freebsd.org/