From owner-freebsd-questions@FreeBSD.ORG Thu Jan 25 15:32:11 2007 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 837E816A400 for ; Thu, 25 Jan 2007 15:32:11 +0000 (UTC) (envelope-from danm@prime.gushi.org) Received: from prime.gushi.org (prime.gushi.org [72.9.101.130]) by mx1.freebsd.org (Postfix) with ESMTP id 4738613C457 for ; Thu, 25 Jan 2007 15:32:11 +0000 (UTC) (envelope-from danm@prime.gushi.org) Received: from prime.gushi.org (localhost [127.0.0.1]) by prime.gushi.org (8.13.8/8.13.8) with ESMTP id l0PFW7Bv091443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jan 2007 10:32:07 -0500 (EST) (envelope-from danm@prime.gushi.org) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=prime.gushi.org; s=primegushiorg; t=1169739127; bh=9BKLvTSzNtLgIjd6Ggl/8RiFu4E=; h=DomainKey-Signature: Received:Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=mfKqqqVpvRlzh5KDs9e0lQhhFiLs66oMGZw+MG ktXTgAP8cwaTZ5zuDXa6eOb+Kt6fOX0cpMmKgWs34V+6ah0A== DomainKey-Signature: a=rsa-sha1; s=primegushiorg; d=prime.gushi.org; c=nofws; q=dns; h=received:date:from:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=LtwOcQ6SvZERc7VEjkMOEr5bjU17hWrXIBp+aJkOGzZa7pljLWPJkUSPP3lbuiLEP M++1bWIEDWW7dxz8fuGJQ== Received: (from danm@localhost) by prime.gushi.org (8.13.8/8.13.6/Submit) id l0PFW7xR091441; Thu, 25 Jan 2007 10:32:07 -0500 (EST) (envelope-from danm) Date: Thu, 25 Jan 2007 10:32:07 -0500 (EST) From: "Dan Mahoney, System Admin" To: Ian Smith In-Reply-To: Message-ID: <20070125102330.F55095@prime.gushi.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-questions@freebsd.org Subject: Re: Problem with "ipfw flush" X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 15:32:11 -0000 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 ---------------------------