From owner-freebsd-security Tue Oct 24 15:39:12 2000 Delivered-To: freebsd-security@freebsd.org Received: from www.kpi.com.au (www.kpi.com.au [203.39.132.210]) by hub.freebsd.org (Postfix) with ESMTP id 862D337B4C5 for ; Tue, 24 Oct 2000 15:39:06 -0700 (PDT) Received: from kpi.com.au (lurker.kpi.com.au [203.39.132.222]) by www.kpi.com.au (8.9.3/8.9.3) with ESMTP id JAA37816; Wed, 25 Oct 2000 09:43:03 +1100 (EST) (envelope-from johnsa@kpi.com.au) Message-ID: <39F6110F.E8B461CA@kpi.com.au> Date: Wed, 25 Oct 2000 09:45:35 +1100 From: Andrew Johns Organization: KPI Logistics X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: peter@sysadmin-inc.com Cc: freebsd-security@FreeBSD.ORG Subject: Re: request for example rc.firewall script References: <003401c03dfe$68b42d80$47010a0a@fire.sysadmininc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Peter Brezny wrote: > I'm working on adding the rules needed to rc.firewall under the 'simple' > sections to allow the script to function as a firewall/nat router for a > small network with private ip's in the 10.x.x.x range. > > The firewall works if i use a simplified script, but the standard > rc.firewall that comes with 4.1 doesn't appear to allow nat to work without > modifying the rc.firewall script more than just putting in your network > info. Correct. > > > i think i need some allow rules before the > > # Stop RFC1918 nets on the outside inteface > > section of the script. > Absolutely, or else after the divert rule, the packet is (optionally) re-injected back into the ruleset at the next rule, where it eventually hits the RFC1918 deny's and gets dropped. Several methods are available: a) Move the RFC1918 deny's in front of the divert rule, which is what you generally want anyway - stopping idiots upstream from you sending packets with those addresses from misconfigured machines. b) Forget the RFC1918 deny's and only allow specific target IP/ports through and explicitly deny everything else. These are just two ideas. tcpdump is most useful in diagnosing these issues, as you'll see the SRC and DST IP/port packets and you can watch the deny logs on the console (or wherever you're sending them) - this assumes that you've got 'deny log' rules of course. HTH AJ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message