From owner-freebsd-hackers  Thu Jul 10 16:02:43 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id QAA03570
          for hackers-outgoing; Thu, 10 Jul 1997 16:02:43 -0700 (PDT)
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA03563
          for <freebsd-hackers@FreeBSD.ORG>; Thu, 10 Jul 1997 16:02:37 -0700 (PDT)
Received: (from daemon@localhost)
	by alpo.whistle.com (8.8.5/8.8.5) id QAA02776;
	Thu, 10 Jul 1997 16:01:09 -0700 (PDT)
Received: from current1.whistle.com(207.76.205.22)
 via SMTP by alpo.whistle.com, id smtpd002772; Thu Jul 10 23:01:02 1997
Message-ID: <33C5690F.2C67412E@whistle.com>
Date: Thu, 10 Jul 1997 15:58:23 -0700
From: Julian Elischer <julian@whistle.com>
Organization: Whistle Communications
X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: Archie Cobbs <archie@whistle.com>
CC: Charles Owens <owensc@enc.edu>, freebsd-hackers@FreeBSD.ORG,
        ari.suutari@ps.carel.fi
Subject: Re: ipfw rules processing order when DIVERTing
References: <199707102204.PAA03534@bubba.whistle.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Archie Cobbs wrote:
> 
> > 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 correct.
> 
> > 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
> 
> There are two reasons for this...
> 
> 1. The new packet (post-diversion) may be different from the old packet
>    (pre-diversion), so it should be checked again to insure that it
>    doesn't avoid any rules that apply to it.
> 
> 2. It's a lot easier to code this way :-)
> 
Just to be devil's advocate,  ;-)
I think it could start processing at the next higher number
after the one it was diverted from..
in other words it could have an implicit 'skipto  (N+1)' rule

the 'divert' word to me suggests that it should come back to the same
place it left from. :)