Problem with "ipfw flush"

Dan Mahoney, System Admin danm at prime.gushi.org
Thu Jan 25 15:32:11 UTC 2007


On Fri, 26 Jan 2007, Ian Smith wrote:

Excellent.  I'll read up on this for a bit.

I suppose my biggest confusion was as to why I could do:

kldload ipfw && ipfw add 65000 allow ip from any to any

but not

ipfw flush && ipfw add 65000 allow ip from any to any

Clearly, the devil is in the output being sent.

Also, the manpage had -q and -f as mutually exclusive, and I missed the 
part about -q implying -f.

There IS one other issue that I encountered.  I have tables and pipes in 
play, and I believe a regular ipfw flush doesn't clear them.  Is there a 
universal "reset EVERYTHING" command?

-Dan



> Re: freebsd-questions Digest, Vol 162, Issue 11
> > Message: 31
>
> On Wed, 24 Jan 2007 19:20:47 -0500 (EST), Dan Mahoney wrote:
>
> > On Wed, 24 Jan 2007, Kevin Kinsey wrote:
> >
> > > Dan Mahoney, System Admin wrote:
> > >> Hey all.
> > >>
> > >> In trying to tweak my firewall setup I'm using a file called
> > >> /etc/ipfw.rules
> > >>
> > >> However, it seems even though I copy my rules perfectly to that file, the
> > >> system freezes up and locks me out when I do:
> > >
> > > /usr/share/examples/ipfw/change_rules.sh?
> >
> > That is a very cool script, however, it appears as though it calls
> > firewall_script on line 131 with "sh", not with ipfw.
> >
> > nohup sh ${firewall_script} ${firewall_type}.new
> >
> > Whereas, etc/rc.firewall calls ipfw on line 299 via the "ipfw" command:
> >
> > ${fwcmd} ${firewall_flags} ${firewall_type}
> >
> > The difference is that the resulting rules file would not be parseable by
> > "sh" since the lines in the file would not contain the "ipfw" command but
> > only the arguments.  As one's in "examples" and the other's in a live
> > startup script, I'd assume the latter to be the correct method.
>
> Either.  Check /etc/defaults/rc.conf and you'll notice that the default
> for firewall_script="/etc/rc.firewall" so 'sh ${firewall_script}' runs
> 'sh /etc/rc.firewall' which runs ipfw -f flush, denying all connections,
> then later, in your case with a given filename, ipfw $flags $pathname
>
> Do you have firewall_quiet="YES" ?  This will help a lot, otherwise ipfw
> writes to the terminal, which after the flush, it can't.  From ipfw(8):
>
>     o   If you are logged in over a network, loading the kld(4) version of
>         ipfw is probably not as straightforward as you would think.  I recom-
>         mend the following command line:
>
>               kldload ipfw && \
>               ipfw add 32000 allow ip from any to any
>
>         Along the same lines, doing an
>
>               ipfw flush
>
>         in similar surroundings is also a bad idea.
>
> > That said, this still does not tell me why a subsequent flush-and-rerun
> > isn't working via ssh.  It works totally fine via the command line, but
> > over ssh it gives:
> >
> > Jan 24 19:10:55 ads-bsh-fwa4 sshd[845]: fatal: Write failed: Permission
> > denied on the console (but by that point my connection's already dropped).
>
> Exactly.
>
> > However, this shouldn't actually stop an already-typed command, should it?
>
> Yes, if it's trying to write to the terminal.  The bottom line is that
> if you want to run it from a command line over ssh, the command must say
> nothing to the terminal until finished.  Even then, if your ssh session
> was being permitted by a keep-state rule you'll still lose your session,
> but as someone else (sorry) mentioned, you can log straight back in.
>
> > Additionally, it doesn't appear that /etc/rc.firewall has the smarts to do
>
> I think you mean /etc/rc.d/ipfw here?
>
> > this, as the "stop" command it lists only disables the kernel firewall
> > structure via sysctl, but does NOT flush the rules, pipes, counts, or the
> > like, so it's not a true "restart".  (the idea being that otherwise, every
> > rule will be added twice -- the flush is a necessary step there).
>
> It is necessary, and it's done on (re)start.  If you're using
> rc.firewall, as it seems you are, then in /etc/rc.d/ipfw:
>
>  ipfw_start()
>  {
>        # set the firewall rules script if none was specified
>        [ -z "${firewall_script}" ] && firewall_script=/etc/rc.firewall
>
> Right?  Then:
>
>        if [ -r "${firewall_script}" ]; then
>                  # .. nat stuff ..
>
>                . "${firewall_script}"
>
> which runs /etc/rc.firewall (in the current shell), starting with a)
> setting firewall_type - in your case, to your rules file, b) setting
> fwcmd='ipfw -q' if firewall_quiet=yes (you do want this!) and then does
> the '${fwcmd} -f flush' then (if not wedged) your rules.
>
> > Even if I add the "flush" command directly to /etc/ipfw.rules, and run
> > ipfw -f /etc/ipfw.rules right from the command line, my connection gets
> > dropped and the rest of the commands do not run.
>
> Try with -q instead (this also implies -f)  RTFM on -q, until grokked.
>
> > In experimenting a bit more, I've found that I can do:
> >
> > nohup ipfw -f /etc/ipfw.rules
> >
> > This allows the rest of the ipfw command to run, but the HUP-on-disconnect
> > still doesn't explain why the command doesn't even finish running.
>
> I think it will IFF you use ipfw_quiet="yes" - and perhaps add a static
> allow rule for your ssh access, before using any stateful rules, as any
> existing dynamic connections will get clobbered on a flush, of course.
>
> Cheers, Ian
>

--

"Why are you wearing TWO grounding straps?"

-John Evans, Ezzi Computers August 23, 2001


--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---------------------------



More information about the freebsd-questions mailing list