From owner-freebsd-ipfw@FreeBSD.ORG Sat Jan 15 16:12:53 2011 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 DDB9D106566B; Sat, 15 Jan 2011 16:12:52 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 385768FC12; Sat, 15 Jan 2011 16:12:52 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id p0FGCBpf022915; Sun, 16 Jan 2011 01:12:21 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p0FGC9R0034055; Sun, 16 Jan 2011 01:12:10 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sun, 16 Jan 2011 01:12:06 +0900 (JST) Message-Id: <20110116.011206.258445491489571055.hrs@allbsd.org> To: smithi@nimnet.asn.au From: Hiroki Sato In-Reply-To: <20110108220300.Q15397@sola.nimnet.asn.au> References: <20110108141111.A15397@sola.nimnet.asn.au> <20110108220300.Q15397@sola.nimnet.asn.au> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sun_Jan_16_01_12_06_2011_533)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Sun, 16 Jan 2011 01:12:36 +0900 (JST) X-Spam-Status: No, score=-100.4 required=13.0 tests=AWL, CONTENT_TYPE_PRESENT, NO_RELAYS, USER_IN_WHITELIST, X_MAILER_PRESENT autolearn=unavailable version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org Cc: jamesbrandongooch@gmail.com, freebsd-ipfw@FreeBSD.org, hrs@FreeBSD.org, naylor.b.david@gmail.com, freebsduser@paradisegreen.co.uk Subject: Re: Request for policy decision: kernel nat vs/and/or natd X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 16:12:53 -0000 ----Security_Multipart(Sun_Jan_16_01_12_06_2011_533)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ian Smith wrote in <20110108220300.Q15397@sola.nimnet.asn.au>: sm> On Sat, 8 Jan 2011 15:02:29 +1100, Ian Smith wrote: sm> > On Fri, 7 Jan 2011, Brandon Gooch wrote: sm> > > On Thu, Dec 23, 2010 at 8:58 AM, Ian Smith wrote: sm> [..] sm> > > > We could: sm> > > > sm> > > > 1) Preference kernel nat over natd when both are enabled. sm> > > sm> > > I vote for #1. sm> > sm> > Thanks. So far, that makes an overwhelming majority of 2 / NIL :) sm> > sm> > I see that hrs@freebsd.org has just grabbed two related PRs: sm> > sm> > kern/148928: [ipfw] Problem with loading of ipfw NAT rules during system startup sm> > conf/153155: [PATCH] [8.2-BETA1] ipfw rules fail to load cleanly on start if nat enabled sm> > sm> > so this seems a good time to work up patches to that effect for review sm> > (/etc/rc.d/ipfw, maybe natd, /etc/rc.firewall) later tonight my time. sm> sm> Ok, the attached patches are against HEAD, which is currently identical sm> to 8-STABLE for these files. rc.d_ipfw.patch also applies to 7-STABLE sm> with an offset but rc.firewall.patch needs more work for 7. I've no box sm> on which to actually run-test tonight, and will be away for a few days. sm> sm> /etc/rc.d/ipfw: sm> . prefer kernel nat (loading ipfw_nat) to natd when both are enabled sm> . add ipdivert to required_modules - when only natd is enabled - as sm> proposed by Thomas Sandford in conf/153155 and also re kern/148928 sm> also fixing the related issue in conf/148137 (and possibly others) sm> . prefix /etc/rc.d/natd to firewall_coscripts when only natd is enabled sm> sm> /etc/rc.d/natd: sm> . seems nothing is needed; has KEYWORD nostart and so should only be sm> started now by ipfw when natd - but not firewall_nat - is enabled sm> sm> /etc/rc.firewall: sm> . move firewall_nat and natd code into a function, setup_nat() sm> preferring kernel firewall_nat to natd if both are enabled sm> . couldn't resist tidying up that code to within 80 columns sm> . call setup_nat also in 'simple' ruleset, with same intent as sm> proposed in conf/148144 by David Naylor sm> . couldn't resist fixing unnecessarily long line in 'workstation' The patches look good to me, but one thing I am wondering is rc.d/natd invocation in rc.d/ipfw. When natd_enable="YES", rc.d/natd invokes the daemon after the rc.d/ipfw script eventually even if firewall_nat_enable="YES". What do you think about adding natd to REQUIRE: line of rc.d/ipfw? Although I did not test it extensively, rc.d/natd can run safely before rc.d/ipfw and using REQUIRE is reasonable instead of using $firewall_coscripts from a viewpoint of the rc.d framework. -- Hiroki ----Security_Multipart(Sun_Jan_16_01_12_06_2011_533)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk0xx1YACgkQTyzT2CeTzy0ZAgCgkg3/wWx+O4zMnrmGz0cJQZxW pecAoMTJiaGS6PSA2hZXsjqLFGug3Jtc =eoX5 -----END PGP SIGNATURE----- ----Security_Multipart(Sun_Jan_16_01_12_06_2011_533)----