From owner-freebsd-ipfw@FreeBSD.ORG Mon Jun 29 03:39:40 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F5F1106566C for ; Mon, 29 Jun 2009 03:39:40 +0000 (UTC) (envelope-from mailinglistmember@mgwigglesworth.net) Received: from mgwigglesworth.net (mail.mgwigglesworth.com [75.146.26.81]) by mx1.freebsd.org (Postfix) with ESMTP id 021A58FC08 for ; Mon, 29 Jun 2009 03:39:39 +0000 (UTC) (envelope-from mailinglistmember@mgwigglesworth.net) To: freebsd-ipfw@freebsd.org Date: Sun, 28 Jun 2009 23:41:25 -0400 Envelope-To: freebsd-ipfw@freebsd.org References: <20090626085530.GA2623@heitec.de> <1246244218.8710.237.camel@localhost> Message-ID: <1246246885.8710.239.camel@localhost> From: "Systems Engineering Group" Received: from [192.168.200.29] (192.168.200.29 [192.168.200.29]) by mgwigglesworth.net; Sun, 28 Jun 2009 23:38:38 -0400 Content-Type: text/plain Organization: M. G. Wigglesworth Holdings, LLC Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1-1mdv2009.1 Content-Transfer-Encoding: 7bit Subject: Re: Any *Working* Examples of kernel-based (IPFW2-based) NAT onFreeBSD 7.1-STABLE? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mailinglistmember@mgwigglesworth.net List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 03:39:40 -0000 The natd command should use the -interface switch, or -n however, the best ways to become informed about natd is to simply run a man natd and read the part about "Running natd," because you will get more out of it. man ipfw is also very informative. On Sun, 2009-06-28 at 22:56 -0400, Systems Engineering Group wrote: > I don't know why you are attempting to be so "eligant" which is a > smart-guy way of saying making something more complex by leaving out > certain things that are still relivant, but "messy" as an experienced > person would see it) if you are new to the methods. > > First, you need to make sure that natd is doing its job, by making sure > that you have natd turned on, and that it is using the correct > interface. > > Second, when you have verified that the natd configuration is accurate, > and usable, the kernel needs to be verified to have the correct options, > and that the ipfw rules, setup. > > You only need divert, and ipfirewall, with ipfirewall_verbose if you > want logging. > > With these kernel options in place, you need to compile and install the > kernel correlative to these installed kernel options for the firewalling > functionality, with divertion to work. > > Given these aspects of the system are installed, then you only need to > place a natd divert rule into the script for your ipfw-centric firewall. > > An example would be to start natd with the following included in either > commandline options, or config file referenced at commandline call to > natd (natd -f /path/to/natd/config) > > at the commandline, or requisite init script: natd -i $divert_iface -d > > This should start natd with the -i switch giving indication to natd what > device is used to be translated (from/to). > > After verfication of initialization of the natd daemon via `sockstat | > grep natd` you should then test divert rules within your ipfw script, or > via dynamic rules that you sent at commandline. > > The simplest way to test the operation of the divert rules is to do the > following. > > ipfw add 100 pass log tcp from any to any in via $divert_iface > > #The traffic coming into the external ip addresss will be "diverted" to > the internal network ip range. > ipfw add 200 divert natd ip from any to any in via $divert_iface > > ## > #Rules 201-499 will be used to filter on the internal addresses after > being mangled by the kernel. > #They will now look like they are going to #the internal address, not > the external ip address, so internal-ip-based > #rules will be affective at this time. > ## > > #This rule will divert traffic going from the internal network to the > external network > ipfw add 500 divert natd ip from any to any out via $divert_iface > > This is a very brief view of an example that works with freebsd. > I would stay away from the complex "elegant" solutions that you > referenced in your original post, on or about June 14th, until you > verify that your solution is working properly. > > Check out the handbook, and the information on firewalling on onlamp.org > and the freebsd handbook. > > I am just doing a datadump of my own experience right now, so if you > have any further questions, then just post them and we can take a look. > > The setup is not very difficult, once you have the basics down. > > I have about thirty rules in my script, but about 20 of them have to do > with filtering different stuff, which is merely skipto to a deletion > rule with logging. > > ipfw and natd are not very difficult to use, however, that simplicity is > also what makes it such a powerful network appliance solution. I have > heard the ipnat + netfilter is supposedly more powerful solution, > because ipnat does certain things better than natd, however, that is > something for further exploration, and I have not had a need to do so, > as of yet. > > I hope this assists your in your setup endeavor. > > Respectfully, > > Martes >