From owner-freebsd-ipfw@FreeBSD.ORG Sun Apr 12 23:04:28 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B17EF2DC for ; Sun, 12 Apr 2015 23:04:28 +0000 (UTC) Received: from sg2nlvphout02.shr.prod.sin2.secureserver.net (sg2nlvphout02.shr.prod.sin2.secureserver.net [182.50.132.196]) by mx1.freebsd.org (Postfix) with ESMTP id 3BADF3F5 for ; Sun, 12 Apr 2015 23:04:27 +0000 (UTC) Received: from ip-118-139-160-95.ip.secureserver.net ([118.139.160.95]) by sg2nlvphout02.shr.prod.sin2.secureserver.net with : DED : id FAvQ1q01523naj201AvQov; Sun, 12 Apr 2015 15:55:25 -0700 x-originating-ip: 118.139.160.95 Received: from gvquest by ip-118-139-160-95.ip.secureserver.net with local (Exim 4.82) (envelope-from ) id 1YhQtL-0007px-Qw for freebsd-ipfw@freebsd.org; Sun, 12 Apr 2015 16:02:15 -0700 To: freebsd-ipfw@freebsd.org Subject: FREE, Unable to deliver your item, #00000246793 Date: Sun, 12 Apr 2015 17:02:15 -0600 From: "FedEx International Economy" Reply-To: "FedEx International Economy" Message-ID: X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2015 23:04:28 -0000 Dear Free, This is to confirm that one or more of your parcels has been shipped. You can review complete details of your order in the find attached. Thanks and best regards, Alan Montgomery, FedEx Delivery Agent. From owner-freebsd-ipfw@FreeBSD.ORG Tue Apr 14 21:09:09 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1E4265E2 for ; Tue, 14 Apr 2015 21:09:09 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A718BD for ; Tue, 14 Apr 2015 21:09:08 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 03D3210CF85; Tue, 14 Apr 2015 14:09:02 -0700 (PDT) Date: Tue, 14 Apr 2015 14:09:01 -0700 From: hiren panchasara To: freebsd-ipfw@freebsd.org Cc: nitroboost@gmail.com Subject: ipfw on just inbound and not outbound Message-ID: <20150414210901.GA10620@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 21:09:09 -0000 --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Apologies if this is something silly but I want to completely eliminate ipfw from outgoing traffic perspective. I just want to have it on incoming. I can always add "allow ip from any to any out" as the first rule but that is still ipfw doing something. Is there a way to tell ipfw to not look at outbound traffic at all? OR, the rule I mentioned is the best that can be done here? cheers, Hiren ps: Please keep me cc'd as I am not subscribed. --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVLYHtXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/l0ugH/iPZ0pLEEMsTi5o1a32ka8T9 DeVPvHgDme+9RBrSuklU5oqAWHFyQvHGP1nc87VnIcRmZM32c73+YVdEcC+HUizT OLd2Xs8i03nZENbIOG4ZQmCxSTw3ryPJNm9bjgclOv5X1/B9StyIQjkEM4bdCdk2 7sGVynmU2nXKW7d6WYZcVzfHdZA06gr+1uLr8OzeEcYXLrx5ptbvXmMSMIknSIi3 eH2xpTi/m+H1e4U6bYCey2ln6qf8NGBfYbNqtcyZMLJDT7Na+Rs80DcyE1a7Z1tf u+hhsqs96AnBGjbPKkQYFwgdgZ+ZUAfQb0bkDFR7Ti7lG4HaMaLktMHKjOevS7c= =4l5N -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq-- From owner-freebsd-ipfw@FreeBSD.ORG Tue Apr 14 21:22:06 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4832991E for ; Tue, 14 Apr 2015 21:22:06 +0000 (UTC) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1C8522E0 for ; Tue, 14 Apr 2015 21:22:05 +0000 (UTC) Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id C3.05.18963.7F48D255; Tue, 14 Apr 2015 14:21:59 -0700 (PDT) X-AuditID: 11973e12-f79456d000004a13-0c-552d84f793a2 Received: from [17.149.236.90] (Unknown_Domain [17.149.236.90]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 7E.51.07752.FB48D255; Tue, 14 Apr 2015 14:21:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: ipfw on just inbound and not outbound From: Charles Swiger In-Reply-To: <20150414210901.GA10620@strugglingcoder.info> Date: Tue, 14 Apr 2015 14:21:59 -0700 Cc: freebsd-ipfw@freebsd.org, nitroboost@gmail.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150414210901.GA10620@strugglingcoder.info> To: hiren panchasara X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUi2FAYpfu9RTfUYPIebYvGHY+ZLd5u2Mdq MX1nM7sDs8eMT/NZPHbOusvusbl9BVsAcxSXTUpqTmZZapG+XQJXRsen94wFDWwVP5/cZWlg vMXSxcjJISFgIjH76h92CFtM4sK99WxdjFwcQgJ7GSWW7fsGV9S25jQLRGIqk8TlY6uYQRLM AloSN/69ZAKxeQX0JB49fQw0iYNDWMBI4tItbxCTTUBNYsJEHhCTU8BK4u8BsIksAqoST+a9 YoUYYiJx+OcqRghbW2LZwtfMEAOtJE68ugVmCwlYStzevxOsV0TAUOL1gzOsICMlBGQlvm6V gziykU3i+y+9CYxCs5CcNgvJabOQbFjAyLyKUSg3MTNHNzPPRC+xoCAnVS85P3cTIyicp9sJ 7WA8tcrqEKMAB6MSD+8JH51QIdbEsuLK3EOM0hwsSuK8l8N1Q4UE0hNLUrNTUwtSi+KLSnNS iw8xMnFwSjUwLrjDI8O61nNW1ZGVytpKE9n2Tg6vDbjX/1iK6+b8jYYnD0us8NjM38vzZcsl dpVe21a1Dx/dhV6+z/h55smrYMHdf74mLH71zDDB2n3C7rU3mFPyjPVm5T5Ir9ZKjdlp1xWz fPoGXqGYA/0bVNXuL35jI5GQn7Z7A8Omw5Zy3S+C01acnPfilxJLcUaioRZzUXEiAIvWEoVI AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUiOPVNlO7+Ft1QgwnvlS0adzxmtni7YR+r xfSdzewOzB4zPs1n8dg56y67x+b2FWwBzFFcNimpOZllqUX6dglcGR2f3jMWNLBV/Hxyl6WB 8RZLFyMnh4SAiUTbmtNQtpjEhXvr2boYuTiEBKYySVw+tooZJMEsoCVx499LJhCbV0BP4tHT x+xdjBwcwgJGEpdueYOYbAJqEhMm8oCYnAJWEn8PgE1kEVCVeDLvFSvEEBOJwz9XMULY2hLL Fr5mhhhoJXHi1S0wW0jAUuL2/p1gvSIChhKvH5xhBRkpISAr8XWr3ARG/llIzpmF5JxZSKYu YGRexShQlJqTWGmml1hQkJOql5yfu4kRFIANhVE7GBuWWx1iFOBgVOLhPeGjEyrEmlhWXJl7 iFGCg1lJhPdtjG6oEG9KYmVValF+fFFpTmrxIUZpDhYlcV6lYJVQIYH0xJLU7NTUgtQimCwT B6dUA2Oy5rLzK+/4vRR1exO7895y0+8Sm78tsMj8qi29Sm5ZDOukibPW7UxVvq12IuWGENvG v/ZBy7Ze6So/9Pelf/hSzsKQq/8tnzB8WBTquFLTu81ogdjMe7PfL5iz5F/js6WpioZLa3Si Xmncidj09SzT/Q5bkRP+U2f2iZy6bBUlvdwhXmafT9xFJZbijERDLeai4kQAYpTx3DwCAAA= X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 21:22:06 -0000 On Apr 14, 2015, at 2:09 PM, hiren panchasara = wrote: > Apologies if this is something silly but I want to completely = eliminate > ipfw from outgoing traffic perspective. I just want to have it on > incoming. I can always add "allow ip from any to any out" as the first > rule but that is still ipfw doing something. >=20 > Is there a way to tell ipfw to not look at outbound traffic at all? >=20 > OR, the rule I mentioned is the best that can be done here? Blocking outbound traffic can be more important to security than = blocking inbound traffic-- for one reason, see BCP 38 / RFC-2827. The rule = you've suggested is the best that can be done, aside from disabling IPFW = entirely. Regards, --=20 -Chuck From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 16 04:01:26 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D44A498 for ; Thu, 16 Apr 2015 04:01:26 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 017B7605 for ; Thu, 16 Apr 2015 04:01:25 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-252-236.lns20.per4.internode.on.net [121.45.252.236]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t3G3fx8o087827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 15 Apr 2015 20:42:04 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <552F2F82.1060506@freebsd.org> Date: Thu, 16 Apr 2015 11:41:54 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: hiren panchasara , freebsd-ipfw@freebsd.org CC: nitroboost@gmail.com Subject: Re: ipfw on just inbound and not outbound References: <20150414210901.GA10620@strugglingcoder.info> In-Reply-To: <20150414210901.GA10620@strugglingcoder.info> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 04:01:26 -0000 On 4/15/15 5:09 AM, hiren panchasara wrote: > Apologies if this is something silly but I want to completely eliminate > ipfw from outgoing traffic perspective. I just want to have it on > incoming. I can always add "allow ip from any to any out" as the first > rule but that is still ipfw doing something. > > Is there a way to tell ipfw to not look at outbound traffic at all? no > > OR, the rule I mentioned is the best that can be done here? yes this touches on something I've been thinking of for a while.. per interface/direction rule sets. but that doesn't exist yet. you could write a kernel module that would disconnect the outgoing packet filter hooks but "hack" comes to mind as a description there. actually.... you could use the ipfw netgraph hook and only hook it up for incoming packets, but it would probably be not much more efficient than just having the rule, and more complicated to set up. > > cheers, > Hiren > > ps: Please keep me cc'd as I am not subscribed. From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 16 07:31:11 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B51DA81; Thu, 16 Apr 2015 07:31:11 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BFE11C47; Thu, 16 Apr 2015 07:31:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t3G7CZEt080759; Thu, 16 Apr 2015 17:12:35 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 16 Apr 2015 17:12:35 +1000 (EST) From: Ian Smith To: Julian Elischer cc: hiren panchasara , freebsd-ipfw@freebsd.org, nitroboost@gmail.com Subject: Re: ipfw on just inbound and not outbound In-Reply-To: <552F2F82.1060506@freebsd.org> Message-ID: <20150416164024.B93161@sola.nimnet.asn.au> References: <20150414210901.GA10620@strugglingcoder.info> <552F2F82.1060506@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 07:31:11 -0000 On Thu, 16 Apr 2015 11:41:54 +0800, Julian Elischer wrote: > On 4/15/15 5:09 AM, hiren panchasara wrote: > > Apologies if this is something silly but I want to completely eliminate > > ipfw from outgoing traffic perspective. I just want to have it on > > incoming. I can always add "allow ip from any to any out" as the first > > rule but that is still ipfw doing something. > > > > Is there a way to tell ipfw to not look at outbound traffic at all? > no > > > > OR, the rule I mentioned is the best that can be done here? > yes > > this touches on something I've been thinking of for a while.. per > interface/direction rule sets. > but that doesn't exist yet. > > you could write a kernel module that would disconnect the outgoing packet > filter hooks > but "hack" comes to mind as a description there. > > actually.... you could use the ipfw netgraph hook and only hook it up for > incoming packets, > but it would probably be not much more efficient than just having the rule, > and more complicated to set up. I'm wondering if the cost of that one rule is even worth worrying about. Hiren, you might try running iperf (ono): a) after 'ipfw disable firewall' b) after just 'ipfw add 20000 allow ip from any to any' c) after say 1000 rules before getting to (b) by such as: for i in `jot - 0 999`; do ipfw add $((i*10+1000)) count ip from any to any done to then calculate a cost per rule. Tens or hundreds of ns? Of course, whether that cost is significant depends on the sort of pps rates you're having (or hoping :) to deal with on the box in question .. > > cheers, > > Hiren > > > > ps: Please keep me cc'd as I am not subscribed. cheers, Ian From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 16 19:08:41 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EDDE1F99; Thu, 16 Apr 2015 19:08:40 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 81A08A59; Thu, 16 Apr 2015 19:08:40 +0000 (UTC) Received: by wiax7 with SMTP id x7so18474884wia.0; Thu, 16 Apr 2015 12:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tds6XN9gf7gno6qYg3tT/dSgxZ2+eVUw6v+kTqSpaV0=; b=wBesyMishPTTmoqjgTum2aKOinL1wGio6HskbXs+jMxu7VwkkJf0OZ6aHY14NLPTnX zK/zyWgZl6egHiiG4GvmMDi51bNdG+RSVh5YyFHXu8lQOF9SHBqyVuKlLFexPNqUhH/Y vri9kRUCbnQTavk3tkJXOtyQwus6uTTdcXZcOoIV2bu1hi4K2sRFVqaQ5wzRdT0fXimb iSXhPrqJVt98iAq80B5A04bk4gQOxMPRnu4J4evkgrxMX1HPvSdgUHqMQpAyaZR3fKGe SQCniX3gNR7PpbQ5ucU4h9jrCO2yr4AHSGcU8ioV3Oczhhjo1QyJemjMfqxhTZsnezod V4og== MIME-Version: 1.0 X-Received: by 10.194.2.145 with SMTP id 17mr62164292wju.79.1429211319080; Thu, 16 Apr 2015 12:08:39 -0700 (PDT) Received: by 10.27.52.132 with HTTP; Thu, 16 Apr 2015 12:08:39 -0700 (PDT) In-Reply-To: <20150416164024.B93161@sola.nimnet.asn.au> References: <20150414210901.GA10620@strugglingcoder.info> <552F2F82.1060506@freebsd.org> <20150416164024.B93161@sola.nimnet.asn.au> Date: Thu, 16 Apr 2015 12:08:39 -0700 Message-ID: Subject: Re: ipfw on just inbound and not outbound From: Jason Wolfe To: Ian Smith Cc: Julian Elischer , hiren panchasara , freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 19:08:41 -0000 Ian, It's not so much the induced latency, but the CPU usage. Simply invoking ipfw causes a noticeable amount of overhead, and with a single rule it clocks in at 5% on the hardware in question. This ranks ipfw_chk in as the 2nd hungriest function, just below tcp_output in the IRQ handler threads with a single rule. With 3 rules, it overtakes the top spot (each adding ~ .3% -.5%). If there were an easy way to gain back that 5% on outbound traffic, we'd gladly take it. It sounds like being able to disconnect paths from ipfw might be a science project for the future, though it does seem it could garner some wider interest. Jason On Thu, Apr 16, 2015 at 12:12 AM, Ian Smith wrote: > On Thu, 16 Apr 2015 11:41:54 +0800, Julian Elischer wrote: > > On 4/15/15 5:09 AM, hiren panchasara wrote: > > > Apologies if this is something silly but I want to completely eliminate > > > ipfw from outgoing traffic perspective. I just want to have it on > > > incoming. I can always add "allow ip from any to any out" as the first > > > rule but that is still ipfw doing something. > > > > > > Is there a way to tell ipfw to not look at outbound traffic at all? > > no > > > > > > OR, the rule I mentioned is the best that can be done here? > > yes > > > > this touches on something I've been thinking of for a while.. per > > interface/direction rule sets. > > but that doesn't exist yet. > > > > you could write a kernel module that would disconnect the outgoing packet > > filter hooks > > but "hack" comes to mind as a description there. > > > > actually.... you could use the ipfw netgraph hook and only hook it up for > > incoming packets, > > but it would probably be not much more efficient than just having the rule, > > and more complicated to set up. > > I'm wondering if the cost of that one rule is even worth worrying about. > > Hiren, you might try running iperf (ono): > > a) after 'ipfw disable firewall' > > b) after just 'ipfw add 20000 allow ip from any to any' > > c) after say 1000 rules before getting to (b) by such as: > > for i in `jot - 0 999`; do > ipfw add $((i*10+1000)) count ip from any to any > done > > to then calculate a cost per rule. Tens or hundreds of ns? > > Of course, whether that cost is significant depends on the sort of pps > rates you're having (or hoping :) to deal with on the box in question .. > > > > cheers, > > > Hiren > > > > > > ps: Please keep me cc'd as I am not subscribed. > > cheers, Ian