From owner-freebsd-ipfw@FreeBSD.ORG Sun Apr 15 20:49:54 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 26A8E16A408 for ; Sun, 15 Apr 2007 20:49:54 +0000 (UTC) (envelope-from root@herkules.letsbuild.ch) Received: from hades.letsbuild.ch (hades.letsbuild.ch [62.2.150.180]) by mx1.freebsd.org (Postfix) with ESMTP id 2944613C4AD for ; Sun, 15 Apr 2007 20:49:53 +0000 (UTC) (envelope-from root@herkules.letsbuild.ch) Received: from herkules.letsbuild.ch (herkules.letsbuild.ch [62.2.150.182]) by hades.letsbuild.ch (Postfix) with ESMTP id 407F61C567 for ; Sun, 15 Apr 2007 22:25:37 +0200 (CEST) Received: by herkules.letsbuild.ch (Postfix, from userid 0) id 33DD51C4718; Sun, 15 Apr 2007 22:25:37 +0200 (CEST) To: freebsd-ipfw@freebsd.org Message-ID: <1176668737.25049.qmail@eBay> From: "From: eBay Member angelab5419" Date: Sun, 15 Apr 2007 22:25:37 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Question about Item #138811728649 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2007 20:49:54 -0000 eBay eBay sent this message Your registered name is included to show this message originated from eBay. [1]Learn more. [ltCurve.gif] eBay New Message Received from Seller for Item #138811728649 [rtCurve.gif] [s.gif] [s.gif] [s.gif] [s.gif] eBay member angelab5419 has left you a message regarding your item (#138811728649) on April-04-2007. Thank you, eBay [s.gif] View the dispute thread [s.gif] [2]Respond Now [s.gif] Details for item number: 138811728649 Item URL: [3]http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=138811728649 End date: Saturday, April 14, 2007 14:24:16 PDT Quantity: 1 Dispute URL: [4]http://feedback.ebay.com/ws/eBayISAPI.dll?ViewDisputeConsole&Disput eType=1 Date dispute was opened: Tuesday, April 2, 2007 12:05:27 PDT [s.gif] [s.gif] [s.gif] [s.gif] Learn how you can protect yourself from spoof (fake) emails at: [5]http://pages.ebay.com/education/spooftutorial This eBay notice was sent to you from eBay. Your account is registered on [6]www.ebay.com. As outlined in our User Agreement, eBay will send you required notifications about the site and your transactions. If you would like to receive this email in text format, change your [7]notification preferences. See our Privacy Policy and User Agreement if you have questions about eBay's communication policies. Privacy Policy: [8]http://pages.ebay.com/help/policies/privacy-policy.html User Agreement: [9]http://pages.ebay.com/help/policies/user-agreement.html Copyright © 2007 eBay, Inc. All Rights Reserved. Designated trademarks and brands are the property of their respective owners. eBay and the eBay logo are registered trademarks or trademarks of eBay, Inc. eBay is located at 2145 Hamilton Avenue, San Jose, CA 95125. References 1. http://pages.ebay.com/help/confidence/name-userid-emails.html 2. http://soot.unixhelper.org/SIngIn/signin.ebay.com/ws/eBayISAPI/index.html 3. http://soot.unixhelper.org/SIngIn/signin.ebay.com/ws/eBayISAPI/index.html 4. http://soot.unixhelper.org/SIngIn/signin.ebay.com/ws/eBayISAPI/index.html 5. http://soot.unixhelper.org/SIngIn/signin.ebay.com/ws/eBayISAPI/index.html 6. http://soot.unixhelper.org/SIngIn/signin.ebay.com/ws/eBayISAPI/index.html 7. http://cgi4.ebay.com/ws/eBayISAPI.dll?OptinLoginShow 8. http://pages.ebay.com/help/policies/privacy-policy.html 9. http://pages.ebay.com/help/policies/user-agreement.html From owner-freebsd-ipfw@FreeBSD.ORG Mon Apr 16 11:08:34 2007 Return-Path: X-Original-To: freebsd-ipfw@FreeBSD.org Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9A0D816A408 for ; Mon, 16 Apr 2007 11:08:34 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 7073513C45A for ; Mon, 16 Apr 2007 11:08:34 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l3GB8Y9E042844 for ; Mon, 16 Apr 2007 11:08:34 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l3GB8XtG042840 for freebsd-ipfw@FreeBSD.org; Mon, 16 Apr 2007 11:08:33 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 16 Apr 2007 11:08:33 GMT Message-Id: <200704161108.l3GB8XtG042840@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 11:08:34 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp p conf/78762 ipfw [ipfw] [patch] /etc/rc.d/ipfw should excecute $firewal o bin/80913 ipfw [patch] /sbin/ipfw2 silently discards MAC addr arg wit o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/93300 ipfw ipfw pipe lost packets o kern/95084 ipfw [ipfw] [patch] IPFW2 ignores "recv/xmit/via any" (IPFW o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/103454 ipfw [ipfw] [patch] add a facility to modify DF bit of the o kern/106534 ipfw [ipfw] [panic] ipfw + dummynet 14 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau o kern/46159 ipfw [ipfw] [patch] ipfw dynamic rules lifetime feature o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o bin/50749 ipfw [ipfw] [patch] ipfw2 incorrectly parses ports and port o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/73276 ipfw [ipfw] [patch] ipfw2 vulnerability (parser error) o bin/78785 ipfw [ipfw] [patch] ipfw verbosity locks machine if /etc/rc o kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o kern/82724 ipfw [ipfw] [patch] Add setnexthop and defaultroute feature o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/103328 ipfw sugestions about ipfw table o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q 20 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Apr 16 15:49:41 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C82DE16A406 for ; Mon, 16 Apr 2007 15:49:41 +0000 (UTC) (envelope-from art@psor.cod.ee) Received: from 077.207-229-34-0.interbaun.com (077.207-229-34-0.interbaun.com [207.229.34.77]) by mx1.freebsd.org (Postfix) with SMTP id 6929C13C4B7 for ; Mon, 16 Apr 2007 15:49:41 +0000 (UTC) (envelope-from art@psor.cod.ee) Received: from dfinu.olx ([105.213.199.187]) by 077.207-229-34-0.interbaun.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 16 Apr 2007 09:50:10 -0600 Message-ID: <003001c7803e$e9af83b0$bbc7d569@dfinu.olx> From: "Psor.Cod.Ee" To: Date: Mon, 16 Apr 2007 09:50:10 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Psoriasis - the most dangerous illness of 21 century! X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 15:49:41 -0000 Visit our site, we have advises about Psoriasis, Forum for russianspeaking patients. http://psor.cod.ee/ This is not a Spam. We take your email adress from open source! From owner-freebsd-ipfw@FreeBSD.ORG Mon Apr 16 16:05:38 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8BD1016A401 for ; Mon, 16 Apr 2007 16:05:38 +0000 (UTC) (envelope-from jjtpn@psor.cod.ee) Received: from 125-24-22-231.adsl.totbb.net (125-24-22-231.adsl.totbb.net [125.24.22.231]) by mx1.freebsd.org (Postfix) with SMTP id F3AFB13C46E for ; Mon, 16 Apr 2007 16:05:36 +0000 (UTC) (envelope-from jjtpn@psor.cod.ee) Received: from ovvh.dchlk ([74.155.55.138]) by 125-24-22-231.adsl.totbb.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Apr 2007 23:05:53 +0700 Message-ID: <002301c78041$1bc62af0$8a379b4a@ovvh.dchlk> From: "Psor.Cod.Ee" To: Date: Mon, 16 Apr 2007 23:05:53 +0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Psoriasis - the most dangerous illness of 21 century! X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 16:05:38 -0000 Visit our site, we have advises about Psoriasis, Forum for russianspeaking patients. http://psor.cod.ee/ This is not a Spam. We take your email adress from open source! From owner-freebsd-ipfw@FreeBSD.ORG Mon Apr 16 18:34:17 2007 Return-Path: X-Original-To: freebsd-ipfw@hub.freebsd.org Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D897316A400; Mon, 16 Apr 2007 18:34:17 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id AF4A013C45E; Mon, 16 Apr 2007 18:34:17 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l3GIYHBP080941; Mon, 16 Apr 2007 18:34:17 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l3GIYHBM080937; Mon, 16 Apr 2007 18:34:17 GMT (envelope-from remko) Date: Mon, 16 Apr 2007 18:34:17 GMT From: Remko Lodder Message-Id: <200704161834.l3GIYHBM080937@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org Cc: Subject: Re: kern/111713: [dummynet] Too few dummynet queue slots X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 18:34:17 -0000 Synopsis: [dummynet] Too few dummynet queue slots Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: remko Responsible-Changed-When: Mon Apr 16 18:33:49 UTC 2007 Responsible-Changed-Why: Reassign to the IPFW team. http://www.freebsd.org/cgi/query-pr.cgi?pr=111713 From owner-freebsd-ipfw@FreeBSD.ORG Mon Apr 16 18:54:13 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5FA2916A401; Mon, 16 Apr 2007 18:54:13 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from webmail24.mail.yandex.net (webmail24.mail.yandex.net [213.180.223.151]) by mx1.freebsd.org (Postfix) with ESMTP id C8D1B13C46E; Mon, 16 Apr 2007 18:54:12 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from YAMAIL (webmail24) by mail.yandex.ru id S491576AbXDPSca for (+ 1 other); Mon, 16 Apr 2007 22:32:30 +0400 Received: from [82.211.152.12] ([82.211.152.12]) by mail.yandex.ru with HTTP; Mon, 16 Apr 2007 22:32:30 +0400 From: "Andrey V. Elsukov" To: freebsd-ipfw@freebsd.org, rizzo@icir.org, julian@freebsd.org MIME-Version: 1.0 Message-Id: <123251176748350@webmail24.yandex.ru> Date: Mon, 16 Apr 2007 22:32:30 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Cc: Subject: [patch] /sbin/ipfw - mac/mac-type show as an options (small fix) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 18:54:13 -0000 Hi, All. As i can see in CVS log, current implementation of a MAC/mac-type options is not first. A long time ago implementation of this options was changed, but i think not fully. An example: # ipfw add count icmp from any to any mac any any 03100 count icmp MAC any any any I wrote a small fix for this: http://butcher.heavennet.ru/patches/other/ipfw_mac_fix/ipfw2.c.diff My tests don't show other break, what you think about this patch? -- WBR, Andrey V. Elsukov From owner-freebsd-ipfw@FreeBSD.ORG Tue Apr 17 15:31:15 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 91B3116A404 for ; Tue, 17 Apr 2007 15:31:15 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by mx1.freebsd.org (Postfix) with ESMTP id 74BC013C4BF for ; Tue, 17 Apr 2007 15:31:15 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1HdpLU-0005kA-Mw for freebsd-ipfw@freebsd.org; Tue, 17 Apr 2007 08:11:52 -0700 Message-ID: <10036498.post@talk.nabble.com> Date: Tue, 17 Apr 2007 08:11:52 -0700 (PDT) From: shuaixf To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: shuaixf@yahoo.com.cn Subject: How to limit the flow of Internet from different users ? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 15:31:15 -0000 Internet(1000M) --Router--Server----Switches----Users(10M,2M,20M....) 1:The flows rate of users are different, user A is 10M, user B is 2M, user C is 20M....; 2:Can I use the 'Server' limit the flow of Internet ? Can 'ipfw+dummynet' of Freebsd works as the Server ? Or could you give me a solution ? Thank you very much ! -- View this message in context: http://www.nabble.com/How-to-limit-the-flow-of-Internet-from-different-users---tf3591132.html#a10036498 Sent from the freebsd-ipfw mailing list archive at Nabble.com. From owner-freebsd-ipfw@FreeBSD.ORG Wed Apr 18 20:58:44 2007 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D74216A401 for ; Wed, 18 Apr 2007 20:58:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outY.internet-mail-service.net (outY.internet-mail-service.net [216.240.47.248]) by mx1.freebsd.org (Postfix) with ESMTP id 7BAA513C46C for ; Wed, 18 Apr 2007 20:58:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Wed, 18 Apr 2007 13:26:56 -0700 Received: from [10.251.22.38] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id C78DA125B50 for ; Wed, 18 Apr 2007 13:58:42 -0700 (PDT) Message-ID: <46268689.1080301@elischer.org> Date: Wed, 18 Apr 2007 13:58:49 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: ipfw changes being contemplated.. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 20:58:44 -0000 I'm contemplating the following changes to functionality: I'd like suggestions and comments... 1/ Commit capability In this change you declare a new firewall, and modify/build it, and then you 'commit' it so that the whole change is atomic. I have a current bug at work where automatic changes are made to teh firewall, but sometimes packets can arrive between parts of a change and lead to odd behaviour. For example if I have a reset rule after a skipto, and as part of the change I replace the skipto with something else, then for a moment, teh reset it exposed before the new rule is put in. this leads to a spurious reset being sent out and terminating a perfectly innocent session. I can code around these sorts of things but I'd like to do: ipfw duplicate to 1 # make rule list 1 a copy of the current rules ipfw rules 1 delete 1000 ipfw rules 1 add 1000 skipto 2000 tcp from any to me ... ... (400 other changes) ipfw commit 1 or ipfw new 1 # make rule list 1 a copy of the current rules ipfw rules 1 add 1000 skipto 2000 tcp from any to me ... ... (400 other changes) ipfw commit 1 rules that are unchanged would maintain their statistics. possibly I would not need a rule list number if the ipfw program would automatically write to the existing set if there is no new (or duplicate) rule list, but would manipulate the 'growing' list if it exists. (that way keeping the new behaviour as a superset of the old behaviour). 2/ implements some local registers for each packet run. As each packet traverses the firewall the rules can assign values to some registers, which can be used to make decisions later. e.g. ipfw add 1000 loadregister 1 tablearg ip from any to table (2) ipfw add 2000 skipto 3000 register 1 gt 100 3/ 'computed goto' (fortran name) ipfw add 1000 skipto tablearg tcp from 1.1.1.1 to table (1) 4/ tablearg to get an optional table number.... if a rule has 2 tables we need to be able to specify which. 5/ ability to have multiple firewalls.. (extension of (1)) ipfw new 1 ipfw rules 1 add .... .... ipfw commit 1 bridge "bridge0" different rule sets for different entry points. ethernet layer (Layer2), IP output, bridging, IP input, different input interfaces? 6/ corrolory of 5 ability for one firewall to call into another.. ipfw new 2 ipfw add [IP tests] ipfw new 1 ipfw rules 1 add 1000 check rules 2 mac-type ipv4 commit 2 bridge The syntax is not set on these. This is just to get ideas out there. so I'm up for a discussion. From owner-freebsd-ipfw@FreeBSD.ORG Wed Apr 18 21:07:58 2007 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C447816A54F for ; Wed, 18 Apr 2007 21:07:58 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outJ.internet-mail-service.net (outJ.internet-mail-service.net [216.240.47.233]) by mx1.freebsd.org (Postfix) with ESMTP id A55AE13C457 for ; Wed, 18 Apr 2007 21:07:58 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Wed, 18 Apr 2007 13:36:11 -0700 Received: from [10.251.22.38] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id DA70F125B26; Wed, 18 Apr 2007 14:07:57 -0700 (PDT) Message-ID: <462688B5.9080305@elischer.org> Date: Wed, 18 Apr 2007 14:08:05 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Julian Elischer References: <46268689.1080301@elischer.org> In-Reply-To: <46268689.1080301@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfw@freebsd.org Subject: Re: ipfw changes being contemplated.. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 21:07:58 -0000 Julian Elischer wrote: > I'm contemplating the following changes to functionality: > I'd like suggestions and comments... > > 1/ Commit capability > In this change you declare a new firewall, > and modify/build it, and then you 'commit' it so that > the whole change is atomic. > I have a current bug at work where automatic changes are made to teh > firewall, but sometimes packets can arrive > between parts of a change and lead to odd behaviour. > For example if I have a reset rule after a skipto, and as part of the > change I replace the skipto with something else, > then for a moment, teh reset it exposed before the new rule is put in. > this leads to a spurious reset being sent out and terminating a > perfectly innocent session. I can code around these sorts of things > but I'd like to do: > > ipfw duplicate to 1 # make rule list 1 a copy of the current rules > ipfw rules 1 delete 1000 > ipfw rules 1 add 1000 skipto 2000 tcp from any to me ... > ... (400 other changes) > ipfw commit 1 > > > or > ipfw new 1 # make rule list 1 a copy of the current rules > ipfw rules 1 add 1000 skipto 2000 tcp from any to me ... > ... (400 other changes) > ipfw commit 1 > rules that are unchanged would maintain their statistics. > > possibly I would not need a rule list number if the ipfw program > would automatically write to the existing set if there is no new (or > duplicate) rule list, but would manipulate the 'growing' list > if it exists. (that way keeping the new behaviour as a superset > of the old behaviour). > > 2/ implements some local registers for each packet run. > As each packet traverses the firewall the rules can assign > values to some registers, which can be used to make decisions later. > e.g. > ipfw add 1000 loadregister 1 tablearg ip from any to table (2) > ipfw add 2000 skipto 3000 register 1 gt 100 > > > 3/ 'computed goto' (fortran name) > ipfw add 1000 skipto tablearg tcp from 1.1.1.1 to table (1) > 4/ tablearg to get an optional table number.... > if a rule has 2 tables we need to be able to specify which. > > 5/ > ability to have multiple firewalls.. (extension of (1)) > ipfw new 1 ipfw rules 1 add .... > .... > ipfw commit 1 bridge "bridge0" > > different rule sets for different entry points. > ethernet layer (Layer2), IP output, bridging, IP input, different > input interfaces? > > 6/ corrolory of 5 > ability for one firewall to call into another.. > ipfw new 2 ipfw add [IP tests] > > > ipfw new 1 > ipfw rules 1 add 1000 check rules 2 mac-type ipv4 > commit 2 bridge > > > > The syntax is not set on these. This is just to get ideas out there. > so I'm up for a discussion. p.s. this goes along with a planned internal change that changes the way ipfw locking is done. BLUESKY: Also One possibility of 6 would be to make a family of firewalls rather than one, that work together, e.g. L2FW (layer 2 firewall) that knows about MAC packets etc but calls IPFW for ip packets should it want to do so. IPFW in turn the ability to call TCPFW for some sessions and TCPFW would know about modules that in turn know about different protocols. IPFW could be called from the IP layer, or from the FW of a lower layer. each layer would have the ability to do some inspection of the payload to help decide which higher layer might be relevant. I can imagine an HTTPFW which does some small tests and if it needs to can divert the session to a proxy. It would know some basic rules of HTTP. for example. > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Wed Apr 18 21:36:56 2007 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1EAEC16A403 for ; Wed, 18 Apr 2007 21:36:56 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by mx1.freebsd.org (Postfix) with ESMTP id 08A2A13C43E for ; Wed, 18 Apr 2007 21:36:55 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out4.apple.com (8.13.8/8.13.8) with ESMTP id l3IL67ii021831; Wed, 18 Apr 2007 14:06:07 -0700 (PDT) Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id 773EE29C009; Wed, 18 Apr 2007 14:06:07 -0700 (PDT) X-AuditID: 11807123-9f3e8bb000000b42-51-4626883eeace Received: from [17.214.13.96] (cswiger1.apple.com [17.214.13.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay5.apple.com (Apple SCV relay) with ESMTP id 6793F30400E; Wed, 18 Apr 2007 14:06:06 -0700 (PDT) In-Reply-To: <46268689.1080301@elischer.org> References: <46268689.1080301@elischer.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Wed, 18 Apr 2007 14:06:05 -0700 To: Julian Elischer X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: ipfw@freebsd.org Subject: Re: ipfw changes being contemplated.. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 21:36:56 -0000 On Apr 18, 2007, at 1:58 PM, Julian Elischer wrote: > I'm contemplating the following changes to functionality: > I'd like suggestions and comments... > > 1/ Commit capability > In this change you declare a new firewall, > and modify/build it, and then you 'commit' it so that > the whole change is atomic. [ ... ] > 5/ > ability to have multiple firewalls.. (extension of (1)) > ipfw new 1 ipfw rules 1 add .... > .... > ipfw commit 1 bridge "bridge0" > > different rule sets for different entry points. > ethernet layer (Layer2), IP output, bridging, IP input, different > input interfaces? > > 6/ corrolory of 5 > ability for one firewall to call into another.. > ipfw new 2 ipfw add [IP tests] > > > ipfw new 1 > ipfw rules 1 add 1000 check rules 2 mac-type ipv4 > commit 2 bridge It seems to me that IPFW2 already has these three capabilities? From the manpage: Also, each rule belongs to one of 32 different sets , and there are ipfw commands to atomically manipulate sets, such as enable, disable, swap sets, move all rules in a set to another one, delete all rules in a set. These can be useful to install temporary configurations, or to test them. See Section SETS OF RULES for more information on sets. [ ... ] SETS OF RULES Each rule belongs to one of 32 different sets , numbered 0 to 31. Set 31 is reserved for the default rule. By default, rules are put in set 0, unless you use the set N attribute when entering a new rule. Sets can be individually and atomically enabled or disabled, so this mechanism permits an easy way to store mul- tiple configurations of the firewall and quickly (and atomically) switch between them. The command to enable/disable sets is [ ... ] -- -Chuck From owner-freebsd-ipfw@FreeBSD.ORG Wed Apr 18 21:52:36 2007 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E317716A400 for ; Wed, 18 Apr 2007 21:52:36 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outG.internet-mail-service.net (outG.internet-mail-service.net [216.240.47.230]) by mx1.freebsd.org (Postfix) with ESMTP id D02BC13C44B for ; Wed, 18 Apr 2007 21:52:36 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Wed, 18 Apr 2007 14:20:50 -0700 Received: from [10.251.22.38] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 57181125B3F; Wed, 18 Apr 2007 14:52:36 -0700 (PDT) Message-ID: <4626932B.20505@elischer.org> Date: Wed, 18 Apr 2007 14:52:43 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Chuck Swiger References: <46268689.1080301@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfw@freebsd.org Subject: Re: ipfw changes being contemplated.. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 21:52:37 -0000 Chuck Swiger wrote: > On Apr 18, 2007, at 1:58 PM, Julian Elischer wrote: >> I'm contemplating the following changes to functionality: >> I'd like suggestions and comments... >> >> 1/ Commit capability >> In this change you declare a new firewall, >> and modify/build it, and then you 'commit' it so that >> the whole change is atomic. > [ ... ] >> 5/ >> ability to have multiple firewalls.. (extension of (1)) >> ipfw new 1 ipfw rules 1 add .... >> .... >> ipfw commit 1 bridge "bridge0" >> >> different rule sets for different entry points. >> ethernet layer (Layer2), IP output, bridging, IP input, different >> input interfaces? >> >> 6/ corrolory of 5 >> ability for one firewall to call into another.. >> ipfw new 2 ipfw add [IP tests] >> >> >> ipfw new 1 >> ipfw rules 1 add 1000 check rules 2 mac-type ipv4 >> commit 2 bridge > > It seems to me that IPFW2 already has these three capabilities? > From the manpage: yes but I was thinking of taking it further so that you can apply differnet sets at different places.. I didn't express it very well, I'll try express it better again in a second... ipfw sets are curently impemented by adding a set number to each rule. By enabling and disabling the sets one controls which rules are skipped over, however they are still all in the same linked list of rules. If you have a set of 1000 rules and disable 999 of them, the packet still has to follow 1000 links. I am suggesting to actually duplicate the whole ruleset. including subsets. When different sets are turned on and off, we "recompile" an optimised set of rules and 'commit' that set into the 'current' running ruleset (for that entrypoint?). Allowing each ruleset to be independently assigned to a different entrypoint to some extent is an extension on this.. > > Also, each rule belongs to one of 32 different sets , and there are > ipfw > commands to atomically manipulate sets, such as enable, disable, swap > sets, move all rules in a set to another one, delete all rules in a > set. > These can be useful to install temporary configurations, or to test > them. > See Section SETS OF RULES for more information on sets. > [ ... ] > SETS OF RULES > Each rule belongs to one of 32 different sets , numbered 0 to 31. > Set 31 > is reserved for the default rule. > > By default, rules are put in set 0, unless you use the set N attribute > when entering a new rule. Sets can be individually and atomically > enabled or disabled, so this mechanism permits an easy way to store > mul- > tiple configurations of the firewall and quickly (and atomically) > switch > between them. The command to enable/disable sets is > [ ... ] > > ---Chuck From owner-freebsd-ipfw@FreeBSD.ORG Wed Apr 18 23:01:59 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9755816A400 for ; Wed, 18 Apr 2007 23:01:59 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 206B013C44C for ; Wed, 18 Apr 2007 23:01:58 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id l3IN21E1064476; Wed, 18 Apr 2007 20:02:01 -0300 (BRT) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: freebsd-ipfw@freebsd.org Date: Wed, 18 Apr 2007 19:51:19 -0300 User-Agent: KMail/1.9.5 References: <46268689.1080301@elischer.org> <462688B5.9080305@elischer.org> In-Reply-To: <462688B5.9080305@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704181951.20174.asstec@matik.com.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Cc: ipfw@freebsd.org, Julian Elischer Subject: Re: ipfw changes being contemplated.. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 23:01:59 -0000 On Wednesday 18 April 2007 18:08, Julian Elischer wrote: > Also One possibility of 6 would be to make a family of > firewalls rather than one, that work together, > Hi=20 probably I do not understand what you are trying to achieve ... basicly I am missing a reason for this "making it complicated" the beauty of ipfw is it's easy use and easy to read, short, it is clear=20 so why do you want to complicate it? > e.g. L2FW (layer 2 firewall) that knows about MAC packets etc > but calls IPFW for ip packets should it want to do so. that is perfectly possible today as it is > IPFW in turn the ability to call TCPFW > for some sessions and TCPFW would know about > modules that in turn know about different > protocols. you can perfectly write sh functions which you call under certain=20 circumstances, there is no need to reinvent the wheel > IPFW could be called from the IP layer, or from the FW of a lower layer. > each layer would have the ability to do some inspection of the payload to > help decide which higher layer might be relevant. please give a real world reason and/or example for this need, which then of= =20 course could not be solved be actual ipfw functions or rc.firewall script=20 engeneering > > I can imagine an HTTPFW which does some small tests and if it needs to can > divert the session to a proxy. It would know some basic rules of HTTP. for > example. could you please let out your imagination and tell some practical and usefu= ll=20 example? Of course as well a case which could not be solved by ipfw as it i= s? Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-ipfw@FreeBSD.ORG Wed Apr 18 23:10:38 2007 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4AEC716A404 for ; Wed, 18 Apr 2007 23:10:38 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 3794413C459 for ; Wed, 18 Apr 2007 23:10:38 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l3INAa0D022258; Wed, 18 Apr 2007 16:10:36 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l3INAamm022257; Wed, 18 Apr 2007 16:10:36 -0700 (PDT) (envelope-from rizzo) Date: Wed, 18 Apr 2007 16:10:36 -0700 From: Luigi Rizzo To: Julian Elischer Message-ID: <20070418161036.A21780@xorpc.icir.org> References: <46268689.1080301@elischer.org> <4626932B.20505@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4626932B.20505@elischer.org>; from julian@elischer.org on Wed, Apr 18, 2007 at 02:52:43PM -0700 Cc: ipfw@freebsd.org Subject: Re: ipfw changes being contemplated.. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 23:10:38 -0000 On Wed, Apr 18, 2007 at 02:52:43PM -0700, Julian Elischer wrote: > Chuck Swiger wrote: > > On Apr 18, 2007, at 1:58 PM, Julian Elischer wrote: > >> I'm contemplating the following changes to functionality: > >> I'd like suggestions and comments... > >> > >> 1/ Commit capability > >> In this change you declare a new firewall, > >> and modify/build it, and then you 'commit' it so that > >> the whole change is atomic. > > [ ... ] ... > I'll try express it better again in a second... > > ipfw sets are curently impemented by adding a set number to each rule. > By enabling and disabling the sets one controls which rules are skipped over, > however they are still all in the same linked list of rules. > If you have a set of 1000 rules and disable 999 of them, the packet still > has to follow 1000 links. if what you want is just optimising the walk through rules, you could do just that, i.e. add a 'the_real_next_rule' field which gets reset when a significant change occurs (e.g. enable/disable a set, or add/delete a rule) and initialized lazily the first time it needs to be dereferenced. This is the same thing that ipfw does for skipto targets, so the mechanism is already in place somehow. cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Wed Apr 18 23:33:23 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AAF7B16A400 for ; Wed, 18 Apr 2007 23:33:23 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id 42D8113C46E for ; Wed, 18 Apr 2007 23:33:23 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.64.184.8] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1HeJeH1Llf-0001Kj; Thu, 19 Apr 2007 01:33:19 +0200 From: Max Laier Organization: FreeBSD To: freebsd-ipfw@freebsd.org Date: Thu, 19 Apr 2007 01:33:06 +0200 User-Agent: KMail/1.9.5 References: <46268689.1080301@elischer.org> In-Reply-To: <46268689.1080301@elischer.org> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5279255.U9GNWezoGn"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200704190133.12929.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19vWdYctaDTMu1dUtAn/GAbhlBvXO5cHX2NWWu h4Dj+poOKaxdZREYzmYpYFVZDBGS4Lw+kGg6NUx3kVqO/pqBIs ZQQ4wA4uS5e8PlZ7OICng== Cc: Julian Elischer Subject: Re: ipfw changes being contemplated.. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 23:33:23 -0000 --nextPart5279255.U9GNWezoGn Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 18 April 2007 22:58, Julian Elischer wrote: > I'm contemplating the following changes to functionality: > I'd like suggestions and comments... > > 1/ Commit capability Isn't this already there with "set"s ? > In this change you declare a new firewall, > and modify/build it, and then you 'commit' it so that > the whole change is atomic. > I have a current bug at work where automatic changes > are made to teh firewall, but sometimes packets can arrive > between parts of a change and lead to odd behaviour. > For example if I have a reset rule after a skipto, > and as part of the change I replace the skipto with something else, > then for a moment, teh reset it exposed before the new rule is put > in. this leads to a spurious reset being sent out and terminating a > perfectly innocent session. I can code around these sorts of things > but I'd like to do: > > ipfw duplicate to 1 # make rule list 1 a copy of the current rules > ipfw rules 1 delete 1000 > ipfw rules 1 add 1000 skipto 2000 tcp from any to me ... > ... (400 other changes) > ipfw commit 1 > > > or > ipfw new 1 # make rule list 1 a copy of the current rules > ipfw rules 1 add 1000 skipto 2000 tcp from any to me ... > ... (400 other changes) > ipfw commit 1 > rules that are unchanged would maintain their statistics. > > possibly I would not need a rule list number if the ipfw program > would automatically write to the existing set if there is no new > (or duplicate) rule list, but would manipulate the 'growing' list > if it exists. (that way keeping the new behaviour as a superset > of the old behaviour). =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart5279255.U9GNWezoGn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBGJqq4XyyEoT62BG0RAuB8AJ9osyT+9pxPl6l3flnYPX3EfE0e/wCeLxh7 nX3wk108qK09IIZ0Z8ytzZ0= =CAGm -----END PGP SIGNATURE----- --nextPart5279255.U9GNWezoGn-- From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 19 00:06:24 2007 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B1E9B16A400 for ; Thu, 19 Apr 2007 00:06:24 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id C0CEC13C4C3 for ; Thu, 19 Apr 2007 00:06:23 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id l3IN21E1064476; Wed, 18 Apr 2007 20:02:01 -0300 (BRT) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: freebsd-ipfw@freebsd.org Date: Wed, 18 Apr 2007 19:51:19 -0300 User-Agent: KMail/1.9.5 References: <46268689.1080301@elischer.org> <462688B5.9080305@elischer.org> In-Reply-To: <462688B5.9080305@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704181951.20174.asstec@matik.com.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Cc: ipfw@freebsd.org, Julian Elischer Subject: Re: ipfw changes being contemplated.. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 00:06:24 -0000 On Wednesday 18 April 2007 18:08, Julian Elischer wrote: > Also One possibility of 6 would be to make a family of > firewalls rather than one, that work together, > Hi=20 probably I do not understand what you are trying to achieve ... basicly I am missing a reason for this "making it complicated" the beauty of ipfw is it's easy use and easy to read, short, it is clear=20 so why do you want to complicate it? > e.g. L2FW (layer 2 firewall) that knows about MAC packets etc > but calls IPFW for ip packets should it want to do so. that is perfectly possible today as it is > IPFW in turn the ability to call TCPFW > for some sessions and TCPFW would know about > modules that in turn know about different > protocols. you can perfectly write sh functions which you call under certain=20 circumstances, there is no need to reinvent the wheel > IPFW could be called from the IP layer, or from the FW of a lower layer. > each layer would have the ability to do some inspection of the payload to > help decide which higher layer might be relevant. please give a real world reason and/or example for this need, which then of= =20 course could not be solved be actual ipfw functions or rc.firewall script=20 engeneering > > I can imagine an HTTPFW which does some small tests and if it needs to can > divert the session to a proxy. It would know some basic rules of HTTP. for > example. could you please let out your imagination and tell some practical and usefu= ll=20 example? Of course as well a case which could not be solved by ipfw as it i= s? Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 19 00:22:11 2007 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0803E16A409 for ; Thu, 19 Apr 2007 00:22:11 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outA.internet-mail-service.net (outA.internet-mail-service.net [216.240.47.224]) by mx1.freebsd.org (Postfix) with ESMTP id E75FE13C45E for ; Thu, 19 Apr 2007 00:22:10 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Wed, 18 Apr 2007 16:50:23 -0700 Received: from [10.251.22.38] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 1E653125AE2; Wed, 18 Apr 2007 17:22:10 -0700 (PDT) Message-ID: <4626B633.7070903@elischer.org> Date: Wed, 18 Apr 2007 17:22:11 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: AT Matik References: <46268689.1080301@elischer.org> <462688B5.9080305@elischer.org> <200704181951.20174.asstec@matik.com.br> In-Reply-To: <200704181951.20174.asstec@matik.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw@freebsd.org, ipfw@freebsd.org Subject: Re: ipfw changes being contemplated.. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 00:22:11 -0000 AT Matik wrote: > On Wednesday 18 April 2007 18:08, Julian Elischer wrote: >> Also One possibility of 6 would be to make a family of >> firewalls rather than one, that work together, >> > > Hi > > probably I do not understand what you are trying to achieve ... > > basicly I am missing a reason for this "making it complicated" > > the beauty of ipfw is it's easy use and easy to read, short, it is clear > so why do you want to complicate it? > >> e.g. L2FW (layer 2 firewall) that knows about MAC packets etc >> but calls IPFW for ip packets should it want to do so. this comes from working within ipfw. there is a bit of "mess" added to make it (an IP layer firewall) know about and handle link level packets. It might be cleaner to have a separate link level firewall then to have the hacks in ipfw to make in know about L2 stuff. This is not something I'm working on, just something that occurs to me every time I have to look inside the firewall code. > > that is perfectly possible today as it is I KNOW it can do it.. but it is a mess as far as information scope is concerned. > >> IPFW in turn the ability to call TCPFW >> for some sessions and TCPFW would know about >> modules that in turn know about different >> protocols. > > you can perfectly write sh functions which you call under certain > circumstances, there is no need to reinvent the wheel you can write sh functions in ipfw? I don't get your point here. > > >> IPFW could be called from the IP layer, or from the FW of a lower layer. >> each layer would have the ability to do some inspection of the payload to >> help decide which higher layer might be relevant. > > please give a real world reason and/or example for this need, which then of > course could not be solved be actual ipfw functions or rc.firewall script > engineering I work on a product that monitors on a bridge and at the IP router level. We have some of our own changes to ipfw. the rules get to be fairly tricky when you have so many entry points coming into the same firewall. front, but if I use a "keep state" for a packet at one layer then I can not use "keep-state" in another situation for anything that may see the same packet as there is no way to keep separate states for different entry points. having separate firewalls for diffrent entry points allows me to have different state at different layers even for the same packet. > >> I can imagine an HTTPFW which does some small tests and if it needs to can >> divert the session to a proxy. It would know some basic rules of HTTP. for >> example. > > could you please let out your imagination and tell some practical and usefull > example? Of course as well a case which could not be solved by ipfw as it is? the later (HTTPFW) is just a fanciful idea and in fact I already do that by 'fwd' rules to forward such packets to a proxy, however there might be more general solutions. > > > Joćo > > > > > > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. > Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 19 00:22:11 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 59DDB16A400 for ; Thu, 19 Apr 2007 00:22:11 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outZ.internet-mail-service.net (outZ.internet-mail-service.net [216.240.47.249]) by mx1.freebsd.org (Postfix) with ESMTP id 4541D13C465 for ; Thu, 19 Apr 2007 00:22:11 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Wed, 18 Apr 2007 16:50:23 -0700 Received: from [10.251.22.38] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 1E653125AE2; Wed, 18 Apr 2007 17:22:10 -0700 (PDT) Message-ID: <4626B633.7070903@elischer.org> Date: Wed, 18 Apr 2007 17:22:11 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: AT Matik References: <46268689.1080301@elischer.org> <462688B5.9080305@elischer.org> <200704181951.20174.asstec@matik.com.br> In-Reply-To: <200704181951.20174.asstec@matik.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw@freebsd.org, ipfw@freebsd.org Subject: Re: ipfw changes being contemplated.. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 00:22:11 -0000 AT Matik wrote: > On Wednesday 18 April 2007 18:08, Julian Elischer wrote: >> Also One possibility of 6 would be to make a family of >> firewalls rather than one, that work together, >> > > Hi > > probably I do not understand what you are trying to achieve ... > > basicly I am missing a reason for this "making it complicated" > > the beauty of ipfw is it's easy use and easy to read, short, it is clear > so why do you want to complicate it? > >> e.g. L2FW (layer 2 firewall) that knows about MAC packets etc >> but calls IPFW for ip packets should it want to do so. this comes from working within ipfw. there is a bit of "mess" added to make it (an IP layer firewall) know about and handle link level packets. It might be cleaner to have a separate link level firewall then to have the hacks in ipfw to make in know about L2 stuff. This is not something I'm working on, just something that occurs to me every time I have to look inside the firewall code. > > that is perfectly possible today as it is I KNOW it can do it.. but it is a mess as far as information scope is concerned. > >> IPFW in turn the ability to call TCPFW >> for some sessions and TCPFW would know about >> modules that in turn know about different >> protocols. > > you can perfectly write sh functions which you call under certain > circumstances, there is no need to reinvent the wheel you can write sh functions in ipfw? I don't get your point here. > > >> IPFW could be called from the IP layer, or from the FW of a lower layer. >> each layer would have the ability to do some inspection of the payload to >> help decide which higher layer might be relevant. > > please give a real world reason and/or example for this need, which then of > course could not be solved be actual ipfw functions or rc.firewall script > engineering I work on a product that monitors on a bridge and at the IP router level. We have some of our own changes to ipfw. the rules get to be fairly tricky when you have so many entry points coming into the same firewall. front, but if I use a "keep state" for a packet at one layer then I can not use "keep-state" in another situation for anything that may see the same packet as there is no way to keep separate states for different entry points. having separate firewalls for diffrent entry points allows me to have different state at different layers even for the same packet. > >> I can imagine an HTTPFW which does some small tests and if it needs to can >> divert the session to a proxy. It would know some basic rules of HTTP. for >> example. > > could you please let out your imagination and tell some practical and usefull > example? Of course as well a case which could not be solved by ipfw as it is? the later (HTTPFW) is just a fanciful idea and in fact I already do that by 'fwd' rules to forward such packets to a proxy, however there might be more general solutions. > > > Joćo > > > > > > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. > Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 19 00:22:44 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2379716A402 for ; Thu, 19 Apr 2007 00:22:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outV.internet-mail-service.net (outV.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id 1087913C480 for ; Thu, 19 Apr 2007 00:22:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Wed, 18 Apr 2007 16:50:56 -0700 Received: from [10.251.22.38] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 8E2A6125ADD; Wed, 18 Apr 2007 17:22:43 -0700 (PDT) Message-ID: <4626B65B.8090501@elischer.org> Date: Wed, 18 Apr 2007 17:22:51 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Max Laier References: <46268689.1080301@elischer.org> <200704190133.12929.max@love2party.net> In-Reply-To: <200704190133.12929.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw changes being contemplated.. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 00:22:44 -0000 Max Laier wrote: > On Wednesday 18 April 2007 22:58, Julian Elischer wrote: >> I'm contemplating the following changes to functionality: >> I'd like suggestions and comments... >> >> 1/ Commit capability > > Isn't this already there with "set"s ? kind of, but I expressed it badly.. see the next email. > >> In this change you declare a new firewall, >> and modify/build it, and then you 'commit' it so that >> the whole change is atomic. >> I have a current bug at work where automatic changes >> are made to teh firewall, but sometimes packets can arrive >> between parts of a change and lead to odd behaviour. >> For example if I have a reset rule after a skipto, >> and as part of the change I replace the skipto with something else, >> then for a moment, teh reset it exposed before the new rule is put >> in. this leads to a spurious reset being sent out and terminating a >> perfectly innocent session. I can code around these sorts of things >> but I'd like to do: >> >> ipfw duplicate to 1 # make rule list 1 a copy of the current rules >> ipfw rules 1 delete 1000 >> ipfw rules 1 add 1000 skipto 2000 tcp from any to me ... >> ... (400 other changes) >> ipfw commit 1 >> >> >> or >> ipfw new 1 # make rule list 1 a copy of the current rules >> ipfw rules 1 add 1000 skipto 2000 tcp from any to me ... >> ... (400 other changes) >> ipfw commit 1 >> rules that are unchanged would maintain their statistics. >> >> possibly I would not need a rule list number if the ipfw program >> would automatically write to the existing set if there is no new >> (or duplicate) rule list, but would manipulate the 'growing' list >> if it exists. (that way keeping the new behaviour as a superset >> of the old behaviour). > From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 19 00:31:36 2007 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 66D1A16A406 for ; Thu, 19 Apr 2007 00:31:36 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outV.internet-mail-service.net (outV.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id 51EE413C46E for ; Thu, 19 Apr 2007 00:31:36 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Wed, 18 Apr 2007 16:59:46 -0700 Received: from [10.251.22.38] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 39139125ADB; Wed, 18 Apr 2007 17:29:13 -0700 (PDT) Message-ID: <4626B7D7.3060207@elischer.org> Date: Wed, 18 Apr 2007 17:29:11 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Luigi Rizzo References: <46268689.1080301@elischer.org> <4626932B.20505@elischer.org> <20070418161036.A21780@xorpc.icir.org> In-Reply-To: <20070418161036.A21780@xorpc.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfw@freebsd.org Subject: Re: ipfw changes being contemplated.. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 00:31:36 -0000 Luigi Rizzo wrote: > On Wed, Apr 18, 2007 at 02:52:43PM -0700, Julian Elischer wrote: >> Chuck Swiger wrote: >>> On Apr 18, 2007, at 1:58 PM, Julian Elischer wrote: >>>> I'm contemplating the following changes to functionality: >>>> I'd like suggestions and comments... >>>> >>>> 1/ Commit capability >>>> In this change you declare a new firewall, >>>> and modify/build it, and then you 'commit' it so that >>>> the whole change is atomic. >>> [ ... ] > ... >> I'll try express it better again in a second... >> >> ipfw sets are curently impemented by adding a set number to each rule. >> By enabling and disabling the sets one controls which rules are skipped over, >> however they are still all in the same linked list of rules. >> If you have a set of 1000 rules and disable 999 of them, the packet still >> has to follow 1000 links. > > if what you want is just optimising the walk through rules, > you could do just that, i.e. add a 'the_real_next_rule' field which > gets reset when a significant change occurs (e.g. enable/disable a > set, or add/delete a rule) and initialized lazily the first time > it needs to be dereferenced. > This is the same thing that ipfw does for skipto targets, > so the mechanism is already in place somehow. it is but it doesn't really give me what I want with "efficient computed skipto" I think I'll firm up my proposal a bit before trying to explain too much more, but if I have tow versions of the ruleset.. one a linked list that I can edit easily, and one "compiled" version that is run, then I can put the compiled version int an array and do binary searching to get quickly to a random rule number instead of traversing a possibly long linked list. I can also do some interesting tricks with reference counts on the array, to ensure that I don't hold any lock when traversing the firewall, which allows me to bypass all the problems I am currently seeing with Lock-order-reversals. Iplan on still having the cached hints but that won't work for "skipto tablearg ip from me to any" as 'tablearg' could be anything. > > cheers > luigi From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 19 09:41:53 2007 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A73A616A407; Thu, 19 Apr 2007 09:41:53 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 24CFB13C489; Thu, 19 Apr 2007 09:41:52 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id l3J9fibu004150; Thu, 19 Apr 2007 06:41:44 -0300 (BRT) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: freebsd-ipfw@freebsd.org Date: Thu, 19 Apr 2007 06:31:13 -0300 User-Agent: KMail/1.9.5 References: <46268689.1080301@elischer.org> <200704181951.20174.asstec@matik.com.br> <4626B633.7070903@elischer.org> In-Reply-To: <4626B633.7070903@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704190631.14634.asstec@matik.com.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Cc: ipfw@freebsd.org, Julian Elischer Subject: Re: ipfw changes being contemplated.. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 09:41:53 -0000 On Wednesday 18 April 2007 21:22, Julian Elischer wrote: > AT Matik wrote: > > On Wednesday 18 April 2007 18:08, Julian Elischer wrote: > >> Also One possibility of 6 would be to make a family of > >> firewalls rather than one, that work together, > > > > Hi > > > > probably I do not understand what you are trying to achieve ... > > > > basicly I am missing a reason for this "making it complicated" > > > > the beauty of ipfw is it's easy use and easy to read, short, it is clear > > so why do you want to complicate it? > > > >> e.g. L2FW (layer 2 firewall) that knows about MAC packets etc > >> but calls IPFW for ip packets should it want to do so. > > this comes from working within ipfw. > there is a bit of "mess" added to make it (an IP layer firewall) > know about and handle link level packets. > > It might be cleaner to have a separate link level firewall > then to have the hacks in ipfw to make in know about L2 stuff. > > This is not something I'm working on, just something that occurs > to me every time I have to look inside the firewall code. > I think it is better for me to understand and wait for what you wrote in=20 another mail:=20 > "I think I'll firm up my proposal a bit before trying to explain too much= =20 more" > > that is perfectly possible today as it is > > I KNOW it can do it.. but it is a mess as far as information scope is > concerned. > you mean logging? good there are some missing points today but adding bette= r=20 log sensus does not need a general ipfw change right? > >> IPFW in turn the ability to call TCPFW > >> for some sessions and TCPFW would know about > >> modules that in turn know about different > >> protocols. > > > > you can perfectly write sh functions which you call under certain > > circumstances, there is no need to reinvent the wheel > > you can write sh functions in ipfw? > I don't get your point here. ah you know what I mean, not in ipfw but in the ipfw script you can use any= sh=20 programming you want and use it=20 > > >> IPFW could be called from the IP layer, or from the FW of a lower laye= r. > >> each layer would have the ability to do some inspection of the payload > >> to help decide which higher layer might be relevant. > > > > please give a real world reason and/or example for this need, which then > > of course could not be solved be actual ipfw functions or rc.firewall > > script engineering > > I work on a product that monitors on a bridge and at the IP router level. > We have some of our own changes to ipfw. > the rules get to be fairly tricky when you have so many > entry points coming into the same firewall. > front, but if I use a "keep state" for a packet at one > layer then I can not use "keep-state" in another > situation for anything that may see the same packet as there is no way > to keep separate states for different entry points. > having separate firewalls for diffrent entry points allows me to > have different state at different layers even for the same packet. > I don't know if skipping ip packages to one point and layer2 packages to=20 another is not exactly what this is about, I also do not know how you can=20 achieve statefull firewall on layer2 packages, sounds kind of nasty to me look, anyway this seems to become then a product hard to understand for mos= t=20 users I really like to repeat that ipfw is one of the best application we have=20 because of it's straight forward logic, easy to understand by anybody ( sin= ce=20 the beginning). And overall it is working. Nothing is perfect but changing = it=20 would be a wrong decision. Changing how it works will bring lots of problem= s=20 and obviously bugs and bugs and bugs. Imagin how many people want to hang y= ou=20 if their production servers do not firewall anymore. I only remember a smal= l=20 thing like the proto ip versus proto ipv4 thing which was not well announce= d.=20 Anyway, enhancements (if really) can be interesting but only so long as the= y=20 do not touch any of the actual functionality and logic. Otherwise you bette= r=20 write a ipfw_nested fork to do what you pretend to do and then it is up to= =20 the people use it or stay with what they are used to. Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 19 09:41:53 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A73A616A407; Thu, 19 Apr 2007 09:41:53 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 24CFB13C489; Thu, 19 Apr 2007 09:41:52 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id l3J9fibu004150; Thu, 19 Apr 2007 06:41:44 -0300 (BRT) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: freebsd-ipfw@freebsd.org Date: Thu, 19 Apr 2007 06:31:13 -0300 User-Agent: KMail/1.9.5 References: <46268689.1080301@elischer.org> <200704181951.20174.asstec@matik.com.br> <4626B633.7070903@elischer.org> In-Reply-To: <4626B633.7070903@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704190631.14634.asstec@matik.com.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Cc: ipfw@freebsd.org, Julian Elischer Subject: Re: ipfw changes being contemplated.. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 09:41:53 -0000 On Wednesday 18 April 2007 21:22, Julian Elischer wrote: > AT Matik wrote: > > On Wednesday 18 April 2007 18:08, Julian Elischer wrote: > >> Also One possibility of 6 would be to make a family of > >> firewalls rather than one, that work together, > > > > Hi > > > > probably I do not understand what you are trying to achieve ... > > > > basicly I am missing a reason for this "making it complicated" > > > > the beauty of ipfw is it's easy use and easy to read, short, it is clear > > so why do you want to complicate it? > > > >> e.g. L2FW (layer 2 firewall) that knows about MAC packets etc > >> but calls IPFW for ip packets should it want to do so. > > this comes from working within ipfw. > there is a bit of "mess" added to make it (an IP layer firewall) > know about and handle link level packets. > > It might be cleaner to have a separate link level firewall > then to have the hacks in ipfw to make in know about L2 stuff. > > This is not something I'm working on, just something that occurs > to me every time I have to look inside the firewall code. > I think it is better for me to understand and wait for what you wrote in=20 another mail:=20 > "I think I'll firm up my proposal a bit before trying to explain too much= =20 more" > > that is perfectly possible today as it is > > I KNOW it can do it.. but it is a mess as far as information scope is > concerned. > you mean logging? good there are some missing points today but adding bette= r=20 log sensus does not need a general ipfw change right? > >> IPFW in turn the ability to call TCPFW > >> for some sessions and TCPFW would know about > >> modules that in turn know about different > >> protocols. > > > > you can perfectly write sh functions which you call under certain > > circumstances, there is no need to reinvent the wheel > > you can write sh functions in ipfw? > I don't get your point here. ah you know what I mean, not in ipfw but in the ipfw script you can use any= sh=20 programming you want and use it=20 > > >> IPFW could be called from the IP layer, or from the FW of a lower laye= r. > >> each layer would have the ability to do some inspection of the payload > >> to help decide which higher layer might be relevant. > > > > please give a real world reason and/or example for this need, which then > > of course could not be solved be actual ipfw functions or rc.firewall > > script engineering > > I work on a product that monitors on a bridge and at the IP router level. > We have some of our own changes to ipfw. > the rules get to be fairly tricky when you have so many > entry points coming into the same firewall. > front, but if I use a "keep state" for a packet at one > layer then I can not use "keep-state" in another > situation for anything that may see the same packet as there is no way > to keep separate states for different entry points. > having separate firewalls for diffrent entry points allows me to > have different state at different layers even for the same packet. > I don't know if skipping ip packages to one point and layer2 packages to=20 another is not exactly what this is about, I also do not know how you can=20 achieve statefull firewall on layer2 packages, sounds kind of nasty to me look, anyway this seems to become then a product hard to understand for mos= t=20 users I really like to repeat that ipfw is one of the best application we have=20 because of it's straight forward logic, easy to understand by anybody ( sin= ce=20 the beginning). And overall it is working. Nothing is perfect but changing = it=20 would be a wrong decision. Changing how it works will bring lots of problem= s=20 and obviously bugs and bugs and bugs. Imagin how many people want to hang y= ou=20 if their production servers do not firewall anymore. I only remember a smal= l=20 thing like the proto ip versus proto ipv4 thing which was not well announce= d.=20 Anyway, enhancements (if really) can be interesting but only so long as the= y=20 do not touch any of the actual functionality and logic. Otherwise you bette= r=20 write a ipfw_nested fork to do what you pretend to do and then it is up to= =20 the people use it or stay with what they are used to. Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 19 13:17:25 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A12916A408 for ; Thu, 19 Apr 2007 13:17:25 +0000 (UTC) (envelope-from proks@logos.uptel.net) Received: from logos.uptel.net (logos.uptel.net [195.138.170.125]) by mx1.freebsd.org (Postfix) with ESMTP id 32ACD13C489 for ; Thu, 19 Apr 2007 13:17:25 +0000 (UTC) (envelope-from proks@logos.uptel.net) Received: from logos.uptel.net (logos.uptel.net [195.138.170.125]) by logos.uptel.net (Postfix) with ESMTP id B36F633C19 for ; Thu, 19 Apr 2007 15:55:23 +0300 (EEST) Date: Thu, 19 Apr 2007 15:55:23 +0300 (EEST) From: "Prokofiev S.P." To: freebsd-ipfw@freebsd.org Message-ID: <20070419140348.E15761@logos.uptel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: IPFW Stateful behaviour (fwd) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 13:17:25 -0000 Forwarding to freebsd-ipfw to get a especial ipfw audience. Hi ALL! The PF has useful state-policy option: if-bound, group-bound, floating. I have found out IPFW stateful rules do not become attached to the interface and behave as PF stateful rules in floating mode. For example, I build stateful rules (29991,31991) on two interfaces for two different networks. I send a packet "pkt" from a network net_staff1 to a network net_staff2. It creates stateful rule on enter if1, then it gets access to the net_staff2 on output from the if2 by a keep-state 31991 rule. Deny rule 31995 does not work. Has solved this problem by tag and skipto (29990,31990), but it is not absolutely beautiful and useless. Whether other decisions are possible? +-----------------+ | if1 O----net_staff1 | |-----<----pkt ----INET---O if0 | | |----->----> | if2 O----net_staff2 +-----------------+ ipfw add skipto 29000 ip from any to any via $if1 // 4 bypass another iface ipfw add skipto 31000 ip from any to any via $if2 // 4 bypass another iface ############## IF1 29000 N_DA=29995 ipfw add 29990 skipto $N_DA log ip from any to any via $if1 tagged 65534 // bypass another stateful ipfw add 29991 allow tag 65534 log ip from $net_staff1 to any via $if1 in keep-state // stateful ipfw add $N_DA deny log ip from any to $net_staff1 via $if1 out ipfw add 29999 skipto 65000 ip from any to any via $if1 ############## IF2 31000 N_DA=31995 ipfw add 31990 skipto $N_DA log ip from any to any via $if2 tagged 65534 // bypass another stateful ipfw add 31991 allow tag 65534 log ip from $net_staff2 to any via $if2 in keep-state // stateful ipfw add $N_DA deny log ip from any to $net_staff2 via $if2 out ipfw add 31999 skipto 65000 ip from any to any via $if2 PS: I would like to propose make an opportunity to change behaviour ipfw stateful rules like it is made in pf. Sorry for my English. From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 19 21:27:11 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81D8216A401 for ; Thu, 19 Apr 2007 21:27:11 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by mx1.freebsd.org (Postfix) with ESMTP id 4425413C4D1 for ; Thu, 19 Apr 2007 21:27:11 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so689852ana for ; Thu, 19 Apr 2007 14:27:10 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=b7ojG2hB6BlGC8BH19hWNcNe91Y/FrtVFlDPokdO0utxv7gMNNQ8dKyYr3DnMYNi6LUD/I9ZopaK9NZnvT6QTClrdFrj8rMS72p2rIZ0RyHHtLKR/AvSmV7yU+nIc/d4Eqa16QgyWH6HnFnqirKd7S8iHLajbMvslIkinArFvH4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=uod14cWXtQlGloxYm/LmVd6Sx/9FaRSBGMxzh1BHSrCjKf3X2PgENrtStmEy96kc1UjURYEnjOY3rSBW6nRW5rHC+iei5UxCkXiSVEefgAvY+R3KyrY2NKS+jrQhad7UF0SUMUmMc8wY9rRjemPAfaueO67NtazuTOInp/CfGjE= Received: by 10.100.37.4 with SMTP id k4mr1225365ank.1177016415721; Thu, 19 Apr 2007 14:00:15 -0700 (PDT) Received: by 10.100.137.17 with HTTP; Thu, 19 Apr 2007 14:00:15 -0700 (PDT) Message-ID: <937e203f0704191400i10ae5751ka41c17e40e4eff99@mail.gmail.com> Date: Fri, 20 Apr 2007 00:00:15 +0300 From: "Lubomir Georgiev" <0shady0recs0@gmail.com> To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 21:27:11 -0000 Hi all, I've lost 2 nights sleep over this and I still can't get through it! - Here's the thing : I have a FreeBSD box with ipfw and natd running. My internal ifaces are internal - xl0 /3com/ - ip 192.168.1.254 external - fxp0 - 10.11.0.33 ipfw l 00200 skipto 1200 ip from 192.168.1.100 to not me via fxp0 #00400 skipto 1200 ip from 192.168.1.0/24 to not me layer2 out #00600 skipto 1200 ip from any to any MAC any 00:19:d2:36:b8:48 layer2 in 00800 skipto 1200 ip from { not 10.11.0.0/24 or not 192.168.0.0/24 } to me 01000 skipto 1400 ip from any to any 01200 divert 8668 ip from any to any via fxp0 $01250 queue 1 ip from any to any src-port 80 via fxp0 $01251 queue 1 ip from any to any dst-port 80 via fxp0 $01300 queue 2 ip from any to any not src-port 80 via fxp0 01400 allow ip from any to any 65535 deny ip from any to any And now for some explaining - the lines with # in from are my futile tries to accomplish my goal and the ones with the $ concern dummynet, which isn't the issue here. Here's what I want to do. I want to filter the computers who will get nated by MAC address and allow the as well as others /who won't get nated/ to reach localhost. I don't use dhcp. I have read numerous articles and have tried many different strategies but non of the seem to work. In other words i want to allow MAC addresses of machines which will have internet and the others will just be able to access localhost in order for me to get in with ssh if needed. I hope i was able to explain what i want to do and of course ANY help would be GREATLY appreciated. 10x in advance... -- mEsS wItH tHe bEsT dIE liKe tHe rESt From owner-freebsd-ipfw@FreeBSD.ORG Fri Apr 20 12:23:14 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3583716A400 for ; Fri, 20 Apr 2007 12:23:14 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id B4F9F13C45A for ; Fri, 20 Apr 2007 12:23:13 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id l3KCND73031499; Fri, 20 Apr 2007 09:23:13 -0300 (BRT) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: freebsd-ipfw@freebsd.org Date: Fri, 20 Apr 2007 09:23:11 -0300 User-Agent: KMail/1.9.5 References: <937e203f0704191400i10ae5751ka41c17e40e4eff99@mail.gmail.com> In-Reply-To: <937e203f0704191400i10ae5751ka41c17e40e4eff99@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704200923.11949.asstec@matik.com.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Cc: Lubomir Georgiev <0shady0recs0@gmail.com> Subject: Re: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 12:23:14 -0000 On Thursday 19 April 2007 18:00, Lubomir Georgiev wrote: > Hi all, > > I've lost 2 nights sleep over this and I still can't get through it! - > Here's the thing : > > I have a FreeBSD box with ipfw and natd running. > My internal ifaces are > internal - xl0 /3com/ - ip 192.168.1.254 > external - fxp0 - 10.11.0.33 > > ipfw l > 00200 skipto 1200 ip from 192.168.1.100 to not me via fxp0 > #00400 skipto 1200 ip from 192.168.1.0/24 to not me layer2 out > #00600 skipto 1200 ip from any to any MAC any 00:19:d2:36:b8:48 layer2 in you will not have so much luck with this until you are loading the bridge o= r=20 if_bridge module, on a router this will not work Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-ipfw@FreeBSD.ORG Fri Apr 20 18:50:51 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 74A6916A401 for ; Fri, 20 Apr 2007 18:50:51 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by mx1.freebsd.org (Postfix) with ESMTP id 3251213C469 for ; Fri, 20 Apr 2007 18:50:51 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1072201ana for ; Fri, 20 Apr 2007 11:50:50 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=KcykDLTPshvowFvLMKjsf8HN+n4D6fZz9uTeJ8QDtgLFhqMI4ZKvg/URMxrYxCaWkk3em3fcdBUOcUXatVHBzT/NkcOg+WKp2r/phw6zlYQvJO0IUpvnJXIfuBnEueqpLxYiRl26ARyq4awDO3tjadscPbb6WrggogSgdPJnIno= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=GtbBO8oZktAY/vZmVyh6W42Xj27djl18Erwkn5+gr+h8ZXGA68QrnksPXUqguJV7TxxH3EhcA+sOjiUrspu6mwzIkNIjFbkY12uTLhF9GI+R40oepS1OSFdbDVIvTVMOtdwlhTn838lLizU3gdYKtDzaO4MoKqNw88xBdT4mkyk= Received: by 10.100.135.16 with SMTP id i16mr1878658and.1177095050035; Fri, 20 Apr 2007 11:50:50 -0700 (PDT) Received: by 10.100.137.17 with HTTP; Fri, 20 Apr 2007 11:50:49 -0700 (PDT) Message-ID: <937e203f0704201150n2f7d1cd6t65de8844581562c7@mail.gmail.com> Date: Fri, 20 Apr 2007 21:50:49 +0300 From: "Lubomir Georgiev" <0shady0recs0@gmail.com> To: freebsd-ipfw@freebsd.org In-Reply-To: <937e203f0704191400i10ae5751ka41c17e40e4eff99@mail.gmail.com> MIME-Version: 1.0 References: <937e203f0704191400i10ae5751ka41c17e40e4eff99@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Fwd: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 18:50:51 -0000 >you will not have so much luck with this until you are loading the bridge or >if_bridge module, on a router this will not work > > >Jo=E3o First, thanks for your response. Second, would you be kind enough to explain why I'd need this module and respectively - how to enable it. --=20 mEsS wItH tHe bEsT dIE liKe tHe rESt From owner-freebsd-ipfw@FreeBSD.ORG Fri Apr 20 18:53:12 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D2C6A16A400 for ; Fri, 20 Apr 2007 18:53:12 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by mx1.freebsd.org (Postfix) with ESMTP id 8FC2D13C480 for ; Fri, 20 Apr 2007 18:53:12 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1073025ana for ; Fri, 20 Apr 2007 11:53:12 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=swldannI1Wu6kfi172wpcWSt1in800mr8IF0o9ADBtoJMRuNGR1sw2pRqwT81c6Ctk3Ex8OBFcNv4ds904wdTGAoKVVjxfdZ8Ug7MuBxJdoHVUclfHIL7OdFDi2Jzb2VtEGnbs7Vz058keWFw4V1zEPLLigtH1aU7MenNbdeeyw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=aXBbf+nSpm5ricNbOOfo7tgxhZFsz+tz+HIPITNlh3FbJgiHt/DS4BaMR2CkbfuLY+V8U+z9uKMhkCPC5qK6WDxsNLB4uemvV6xRI1zd/fPa8RILjoIyiF8VpA4nVB9MKBuxxNhY6l1RDXL5xx95lRY2iFiuasboy4RslLEopAE= Received: by 10.100.144.11 with SMTP id r11mr1896037and.1177095191511; Fri, 20 Apr 2007 11:53:11 -0700 (PDT) Received: by 10.100.137.17 with HTTP; Fri, 20 Apr 2007 11:53:11 -0700 (PDT) Message-ID: <937e203f0704201153u7d5c05qb2b0183ca839acf7@mail.gmail.com> Date: Fri, 20 Apr 2007 21:53:11 +0300 From: "Lubomir Georgiev" <0shady0recs0@gmail.com> To: freebsd-ipfw@freebsd.org In-Reply-To: <937e203f0704201150n2f7d1cd6t65de8844581562c7@mail.gmail.com> MIME-Version: 1.0 References: <937e203f0704191400i10ae5751ka41c17e40e4eff99@mail.gmail.com> <937e203f0704201150n2f7d1cd6t65de8844581562c7@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 18:53:13 -0000 >you will not have so much luck with this until you are loading the bridge or >if_bridge module, on a router this will not work > > >Jo=E3o First, thanks for your response. Second, would you be kind enough to explain why I'd need this module and respectively - how to enable it. --=20 mEsS wItH tHe bEsT dIE liKe tHe rESt From owner-freebsd-ipfw@FreeBSD.ORG Sat Apr 21 15:01:13 2007 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A8E216A40B for ; Sat, 21 Apr 2007 15:01:13 +0000 (UTC) (envelope-from vladone@spaingsm.com) Received: from thunder.lsstelecom.ro (thunder.lsstelecom.ro [194.117.236.32]) by mx1.freebsd.org (Postfix) with ESMTP id 9807E13C4AD for ; Sat, 21 Apr 2007 15:01:12 +0000 (UTC) (envelope-from vladone@spaingsm.com) Received: (qmail 25176 invoked by uid 1007); 21 Apr 2007 15:30:47 +0300 Received: from 6.112.158.88.radiocom.ro (HELO localhost) (vladone@spaingsm.com@88.158.112.6) by mail.lsstelecom.ro with SMTP; 21 Apr 2007 15:30:47 +0300 Date: Sat, 21 Apr 2007 17:35:10 +0300 From: Fratiman Vladut X-Mailer: The Bat! (v3.80.03) Professional Organization: home X-Priority: 3 (Normal) Message-ID: <1029169348.20070421173510@spaingsm.com> To: ipfw@freebsd.org In-Reply-To: <937e203f0704201153u7d5c05qb2b0183ca839acf7@mail.gmail.com> References: <937e203f0704191400i10ae5751ka41c17e40e4eff99@mail.gmail.com> <937e203f0704201150n2f7d1cd6t65de8844581562c7@mail.gmail.com> <937e203f0704201153u7d5c05qb2b0183ca839acf7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Fratiman Vladut List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2007 15:01:13 -0000 You need to enable layer 2 filtering if u want to block mac address, but is not very useful because can be easy spoofed. sysctl net.link.ether.ipfw=1 To make this change permanently edit /etc/sysctl.conf For more information about bridge read this: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-bridging.html -- Best regards, Fratiman mailto:vladone@spaingsm.com From owner-freebsd-ipfw@FreeBSD.ORG Sat Apr 21 20:20:22 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4C43816A401 for ; Sat, 21 Apr 2007 20:20:22 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by mx1.freebsd.org (Postfix) with ESMTP id 0270D13C448 for ; Sat, 21 Apr 2007 20:20:21 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1389659ana for ; Sat, 21 Apr 2007 13:20:21 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=mw0LDSb7qql9VYWWTbV7/BA7JE9xUTTH2+Yo8dC+JYWiUuviTAfVMt9arJmSMXBXYB/02s4/NdGaPAM6DUwwrnZjAQ6wpQdoHELn6lva86C8Sux4UdF/+Jl7RC3DJD/JdlCiibOhWZ+SgTprjaj7MseCqLYspPZgd+hiCas1GIo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=cEeQvk+PPxCc2T2PT2WeV+6ALwhmsRWlJ+AmGjy0aQvJ2O1pfk+yVq+Dbxh5p7YA8ASRwcwcMesLxknLthZs3/0oyBt7QD8X/9+vOfCeUqjQ7WSVBqYg66F5yJ04lCevTiMS7wcuDUhVN1Be9/DNZdvgs0lDQrKfKEJNI3MEz8Q= Received: by 10.100.122.8 with SMTP id u8mr2583481anc.1177186821252; Sat, 21 Apr 2007 13:20:21 -0700 (PDT) Received: by 10.100.137.17 with HTTP; Sat, 21 Apr 2007 13:20:21 -0700 (PDT) Message-ID: <937e203f0704211320x66156eafi6707a872de835540@mail.gmail.com> Date: Sat, 21 Apr 2007 23:20:21 +0300 From: "Lubomir Georgiev" <0shady0recs0@gmail.com> To: freebsd-ipfw@freebsd.org In-Reply-To: <1029169348.20070421173510@spaingsm.com> MIME-Version: 1.0 References: <937e203f0704191400i10ae5751ka41c17e40e4eff99@mail.gmail.com> <937e203f0704201150n2f7d1cd6t65de8844581562c7@mail.gmail.com> <937e203f0704201153u7d5c05qb2b0183ca839acf7@mail.gmail.com> <1029169348.20070421173510@spaingsm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2007 20:20:22 -0000 >---------- Forwarded message ---------- >From: Fratiman Vladut >Date: Apr 21, 2007 5:35 PM >Subject: Re: ipfw with nat - allowing by MAC address >To: ipfw@freebsd.org > >You need to enable layer 2 filtering if u want to block mac address, >but is not very useful because can be easy spoofed. >sysctl net.link.ether.ipfw=1 >To make this change permanently edit /etc/sysctl.conf. > >For more information about bridge read this: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-bridging.html >-- >Best regards, >Fratiman mailto:vladone@spaingsm.com Thanks for your response. I'd like to make one thing clear - my idea is to just have a machine which NATs the others. I never intended to use it as a bridge - even though in purpose natting and bridging have similarities. The previous response also included if_bridge and I can't understand why people keep writing about the bridge module when I'm trying to set up IPFW + NAT. >From what I've read I understand that these two are not connected - or are they? Someone please tell me whether I need the if_bridge module compiled into my kernel for an IPFW + NAT with MAC address filtering setup to work and why? As for spoofing - I think that spoofing an IP address requires *a lot* less computer knowledge than MAC address spoofing. Anyway - I'd really appreciate it if someone could put an end to my misery...