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?


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).


> 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:

       # 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

freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to