Problem with "ipfw flush"

[Ian Smith]

 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