From owner-freebsd-hackers Thu Jul 10 10:34:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA13679 for hackers-outgoing; Thu, 10 Jul 1997 10:34:15 -0700 (PDT) Received: from server.local.sunyit.edu (A-V25.rh.sunyit.edu [150.156.211.85]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA13670 for ; Thu, 10 Jul 1997 10:34:12 -0700 (PDT) Received: from localhost (brightmn@localhost) by server.local.sunyit.edu (8.8.5/8.8.5) with SMTP id NAA26183; Sun, 22 Jun 1997 13:42:42 GMT Date: Sun, 22 Jun 1997 13:42:42 +0000 (GMT) From: BRiGHTMN To: Charles Owens cc: hackers list FreeBSD , ari.suutari@ps.carel.fi Subject: Re: ipfw rules processing order when DIVERTing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk it works like so: first matched = action if you want anything firewalled out put it before it hits natd /sbin/ipfw -f flush /sbin/ipfw add 100 deny ip from evil.place.org to any /sbin/ipfw add 200 divert 6668 all from any to any via ed0 /sbin/ipfw add 300 pass all from any to any the numbers are the order that way if you decide to change anything you can: /sbin/ipfw delete 200 to get rid of the natd... if you want you can take a look at my natd configuration files i'm going to post them on my webpage: www.cs.sunyit.edu/~perlsta it should be up later tonight... > Hi all, > > I'm a bit unsure about the order in which ipfw rules get processed in > relation to a DIVERT rule that calls natd(8). Note the last few sentences > from this excerpt from the natd(8) man page: > > /sbin/ipfw -f flush > /sbin/ipfw add divert 6668 all from any to any via ed0 > /sbin/ipfw add pass all from any to any > The second line depends on your interface and assumes that you've > updated /etc/services as above. If you specify real firewall rules, > ---> it's best to specify line 2 at the start of the script so that natd > ---> sees all packets before they are dropped by the firewall. The fire- > ---> wall rules will be run again on each packet after translation by > ---> natd, minus any divert rules. > > If I take this as literally as I can, I interpret it as follows > > * Rules before divert rule processed > * Divert rule ships all packets not dropped by above rules > to natd for address translation > * Packets return from natd and are then subjected to ALL rules, > except this time divert rule is skipped > > This is somewhat counter-intuitive to me. If this how it works, what is > the reason for this design, since, as I think about it, there must be a > performance penalty to this approach (multiple passes of rules). I had > expected it to work like this: > > * Rules before divert rule processed > * Divert rule ships all packets not dropped by above rules > to natd for address translation > * Packets return from natd and remaining rules after divert rule > are processed > > What is the real story? > > Thanks very much, > --- > ------------------------------------------------------------------------- > Charles N. Owens Email: owensc@enc.edu > http://www.enc.edu/~owensc > Network & Systems Administrator > Information Technology Services "Outside of a dog, a book is a man's > Eastern Nazarene College best friend. Inside of a dog it's > too dark to read." - Groucho Marx > ------------------------------------------------------------------------- > >