Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 22 Mar 2001 09:20:09 +0200
From:      "Patrick O'Reilly" <>
To:        <ipfw@FreeBSD.ORG>
Subject:   RE: cvs commit: src/sys/netinet ip_fw.c
Message-ID:  <>
In-Reply-To: <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

If I may throw in my 2c worth - from the point of view of a user (I'd love
to be a contributor, but will need to learn some C first ;-) I think the
idea of being able to 'pin' some rules to survive a flush is excellent.  The
default rule (# 65535) behaves somewhat like that already.

I guess it would be nice to be able to do something like:
ipfw -P add 1000 allow udp from any to any 53            # -P: permanent
ipfw    add 1100 allow tcp from 10.x.x.x to any 80
and then when you wish to delete the fancy rules but keep the base system
running you could do:
ipfw delete all
Which would delete ALL rules, but NOT those created the -P (permanent) flag.

ipfw flush would still flush the lot.

One great advantage of this would be that it could be much safer to remotely
administer a firewall.  If the rules enabling the remote administration are
set up with -p then you cannot make the mistake of locking yourself out
(well, you could still 'flush' yourself out, but a 'delete all' would be

And, by the way, an option to 'delete #-#' would be nice too.

Forgive me if I am sticking my nose where it does not belong - but please
understand that I am 100% in support of the concepts of this change.

Since I am not in a position to help with writing code at present, let me at
least offer my support in testing of these changes if you need that.

Patrick O'Reilly.

-----Original Message-----
From: owner-freebsd-ipfw@FreeBSD.ORG
[mailto:owner-freebsd-ipfw@FreeBSD.ORG]On Behalf Of Ruslan Ermilov
Sent: 21 March 2001 12:44
To: Paul Richards
Cc: ipfw@FreeBSD.ORG
Subject: Re: cvs commit: src/sys/netinet ip_fw.c

On Wed, Mar 21, 2001 at 09:20:21AM +0000, Paul Richards wrote:
> Move to developers.
[Redirected to -ipfw, see Committer's Guide for -developers usage rules]

> Ruslan Ermilov wrote:
> >
> > On Wed, Mar 21, 2001 at 12:19:32AM -0800, Paul Richards wrote:
> > > paul        2001/03/21 00:19:32 PST
> > >
> > >   Modified files:
> > >     sys/netinet          ip_fw.c
> > >   Log:
> > >   Only flush rules that have a rule number above that set by a new
> > >   sysctl, net.inet.ip.fw.permanent_rules.
> > >
> > >   This allows you to install rules that are persistent across flushes,
> > >   which is very useful if you want a default set of rules that
> > >   maintains your access to remote machines while you're reconfiguring
> > >   the other rules.
> > >
> > >   Reviewed by:        Mark Murray <>
> > >
> > You asked for a review and committed this while many of us were asleep!
> There's always people asleep in the project. This wasn't a major
> architectural change, I just thought it worthwhile for a second pair of
> eyes to look it over and Mark's more than qualified for that.
> > What I would really prefer is if we had a flag that marked individual
> > rules as permanent.  Then flush command would skip these rules, and
> > another flush command would ignore this flag.
> I thought about that first, but there's no bits left in the flag.
Really?  0x80000000 is unused.  Or, alternatively, you may change
the IP_FW_F_COMMAND to 0x0000007F (we are unlikely to have more than
128 actions) and use 0x00000080.  I propose the name IP_FW_F_PINNED.

> This solution has minimal impact on the implementation whereas changing
> structure is a lot more intrusive. I'd also have had to fix the userland
> parser to recognise a token for persistent rules, whereas a sysctl was
> also a minimal impact change.
I think you should back this out and reimplement this.
I can do this, if you wish.  :-)

> One thing I did think would be useful though is being able to pass a
> range to flush, i.e. ipfw flush 1000-1999.
Nope, the flush command should flush all rules, and probably also check
the IP_FW_F_PINNED bit in the flags.  If the latter is set, it should
delete pinned rules as well.  The same should be done for "delete".

Ruslan Ermilov		Oracle Developer/DBA,		Sunbay Software AG,		FreeBSD committer,
+380.652.512.251	Simferopol, Ukraine	The Power To Serve	Enabling The Information Age

To Unsubscribe: send mail to
with "unsubscribe freebsd-ipfw" in the body of the message

To Unsubscribe: send mail to
with "unsubscribe freebsd-ipfw" in the body of the message

Want to link to this message? Use this URL: <>