Re: ipf ipnat iptables

["Bob T. Kat" <bobkat79@charter.net>]

Sorry, after going back and reading that I realize just how fragged I
was when I wrote it,  it's overworked system admin syndrome, a little
better explanation of what I was trying to spew:

Ipf/ipnat (old bsd firewalling) = rules are processed as last match
wins, in other words all the rules are processed and the last rule that
is matched is the one that is gone with, this is much like English

Example:  
No pets are allowed (first rule)
Except brown and grey cats (second rule)
Except penguins (third rule)

This way seems to be easiest for me to process in my head with firewall
rules because I'm used to it, and the general rules can be applied first
with the exceptions added as you find things you want to let through.

Iptables/ipchains (new style firewalling) = rules are processed as first
match wins, in other words as soon as a packet matches a rule it jumps
to the target (accept, deny, reject) and rule processing stops, this is
the opposite as the ipf/ipnat system.

Example:
Brown and grey cats allowed (first rule)
Penguins allowed (second rule)
No pets allowed (third rule)

Where this ran into a problem with me is I was writing all my general
deny rules first and nothing was getting through, of course I'm sitting
back completely boggled by this because I've got my allow rules after
the general deny everythings, I hope this makes a little more sense than
my off the cuff blast to the list the first time

Bob T. Kat


 Progress (n.): The process through which Usenet has evolved from smart
people in front of dumb terminals to dumb people in front of smart
terminals.
 - obs@burnout.demon.co.uk (obscurity) -

 -----Original Message-----
From: silug-discuss-owner@silug.org
[mailto:silug-discuss-owner@silug.org] On Behalf Of greg
Sent: Thursday, October 31, 2002 8:10 PM
To: silug-discuss@silug.org
Subject: Re: ipf ipnat iptables

well formed and concise, thanks for that nugget


"Bob T. Kat" wrote:

> Hmmm this is interesting, thanks steve for the link, also another good
> link for this is http://www.linuxguruz.org/iptables/
> But they all seem to ignore one important piece of information which
if
> you used ipchains you already knew, if you are a user of ipf/ipnat you
> know that you write the general rule first and then start writing the
> specific rules, hmm why am I writing rules to allow with iptables and
> nothings getting through, well it seems as if it's because someone
> decided that it all needs to be done backwards, so if anyone out there
> is looking at this before you start banging your head against the wall
> remember the first match wins (reading through the ipchains section of
> an older book the author made this clear for users of the older ipfw),
> so now it seems to make a little more sense, just got to get used to
the
> idea of chains and the natting and filtering being done in the same
app
> and I should be good
> Thanks again
>
> Bob T. Kat
>
> "We demand rigidly defined areas of doubt and uncertainty."
>   - Douglas Adams -
>
> -----Original Message-----
> From: silug-discuss-owner@silug.org
> [mailto:silug-discuss-owner@silug.org] On Behalf Of Steven Pritchard
> Sent: Wednesday, October 30, 2002 9:39 PM
> To: silug-discuss@silug.org
> Subject: Re: ipf ipnat iptables
>
> On Wed, Oct 30, 2002 at 04:21:47PM -0600, Bob T. Kat wrote:
> > does anyone know of a good document on the web that explains the
> > conversion from ipf/ipnat line of thinking to iptables line of
> > thinking
>
> I don't know about that, but there is a ton of documentation here:
>
>     http://www.netfilter.org/documentation/
>
> Specifically, when I was moving from ipchains to iptables, I found
> this explanation of how packets are handled by the various chains
> helpful:
>
>
>
http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO-6.ht
> ml
>
> The basic idea is that the INPUT chain filters packets destined for
> the local box, the OUPUT chain filters everything leaving from the
> local box, and the FORWARD chain handles everything being routed
> otherwise.  (Those are all in the filter table.  Other tables, such as
> the nat table, are used to do packet mangling.)
>
> Since you know the input and output interfaces in the FORWARD chain,
> you want to filter by pairs of interfaces.  For example, you might
> want to allow anything from the internal network to the outside world,
> but most likely you want to block anything going the other direction
> (other than established connections, of course).  The rules to get
> that effect look something like this (assuming eth0 is inside and eth1
> is out):
>
>     iptables -P FORWARD DROP # Default action is to drop everything.
>     iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
>     iptables -A FORWARD -i eth1 -o eth0 \
>         -m state --state 'ESTABLISHED,RELATED' -j ACCEPT
>
> Of course, there's a bunch of junk that you'll want to include to make
> everything happy, which is why I wrote my genfw script.  It will
> either generate a shell script to do all your rules, or just run
> iptables and apply all the rules.  If you run it with no options, it
> will generate the shell script, so it should be nice for learning
> purposes.  (Create the config file, run genfw, look at the output.)
>
> Steve
> --
> steve@silug.org           | Southern Illinois Linux Users Group
> (618)398-7360             | See web site for meeting details.
> Steven Pritchard          | http://www.silug.org/
>
> -
> To unsubscribe, send email to majordomo@silug.org with
> "unsubscribe silug-discuss" in the body.
>
> -
> To unsubscribe, send email to majordomo@silug.org with
> "unsubscribe silug-discuss" in the body.


-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.


-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.