From owner-freebsd-isp  Mon Apr 14 16:29:53 1997
Return-Path: <owner-isp>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id QAA23772
          for isp-outgoing; Mon, 14 Apr 1997 16:29:53 -0700 (PDT)
Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA23766
          for <isp@freebsd.org>; Mon, 14 Apr 1997 16:29:47 -0700 (PDT)
Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id JAA03036; Tue, 15 Apr 1997 09:28:00 +1000
From: Darren Reed <darrenr@cyber.com.au>
Message-Id: <199704142328.JAA03036@plum.cyber.com.au>
Subject: Re: IP Filter ...
To: jgreco@solaria.sol.net (Joe Greco)
Date: Tue, 15 Apr 1997 09:27:59 +1000 (EST)
Cc: ipfilter@postbox.anu.edu.au, isp@freebsd.org
In-Reply-To: <199704141935.OAA07048@solaria.sol.net> from "Joe Greco" at Apr 14, 97 02:35:18 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-isp@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In some mail I received from Joe Greco, sie wrote
[...]
> My problem seems to revolve around my inability to either control the
> order of processing within the chain, or what could be considered a
> minor deficiency in the filter rules: a lack of negation.
[...]
> The first section, "bad address" rejection, can be handled in a mildly
> roundabout way by using "quick" to always terminate rule processing as
> soon as we detect something bad.
> 
> The mess starts in the second section, with the second rule.  (I am quite
> aware that some of these rules overlap with previous rules.)
> 
> I stop all packets leaving my network, but then on the next line(s)
> I explicitly allow packets with a source address that originated on
> my net to pass.  No problem.
> 
> Then I do the same thing for inbound destination addresses.  I think that
> I am still fine.
> 
> However, now, think about what any local policy additions would do to
> the state of a packet that would otherwise have been blocked.
> 
> pass in on any port domain to any port domain
> 
> as a somewhat useless example.  If someone on the local ethernet were
> spoofing DNS, this would short-circuit the previous determination that 
> the packet was illegitimate.  (Yes, I know I could qualify the addresses
> in that line, but that gets complex rather quickly in a nontrivial
> configuration).

"Spoof" which DNS ?  I can't see that there is any option (here) to putting
addresses in.

> I think what I am really looking for is a rule that simply checks the
> current state of the packet at a given point in the rule processing list
> and if it is set a particular way, terminates rule processing.

I don't quite get what you're saying here.

> Or, maybe, better yet, some sort of "goto" conditional.  I come from a
> digital logic background and I can trivially translate a complex logic
> equation of this sort into a decision tree, but one needs to have some
> control...

Can you illustrate how negation/goto would help you here ?

Darren