Date: Wed, 24 Jan 2007 19:20:47 -0500 (EST) From: "Dan Mahoney, System Admin" <danm@prime.gushi.org> To: Kevin Kinsey <kdk@daleco.biz> Cc: questions@freebsd.org Subject: Re: Problem with "ipfw flush" Message-ID: <20070124185059.P55095@prime.gushi.org> In-Reply-To: <45B7D086.7040400@daleco.biz> References: <20070124152310.E82156@prime.gushi.org> <45B7D086.7040400@daleco.biz>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
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?
Additionally, it doesn't appear that /etc/rc.firewall has the smarts to do
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).
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.
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.
-Dan
--
"What's with the server farm down in the basement?"
-Spider, Three Skulls Commons at Selden House, 4/15/00
--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070124185059.P55095>