Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 16 Jan 2011 01:12:06 +0900 (JST)
From:      Hiroki Sato <hrs@FreeBSD.org>
To:        smithi@nimnet.asn.au
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
Message-ID:  <20110116.011206.258445491489571055.hrs@allbsd.org>
In-Reply-To: <20110108220300.Q15397@sola.nimnet.asn.au>
References:  <AANLkTinXREwAvvSQDtA65je2OdWcDQ9qR8rCh3my_26A@mail.gmail.com> <20110108141111.A15397@sola.nimnet.asn.au> <20110108220300.Q15397@sola.nimnet.asn.au>

next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Sun_Jan_16_01_12_06_2011_533)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ian Smith <smithi@nimnet.asn.au> 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 <smithi@nimnet.asn.au> 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)----



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110116.011206.258445491489571055.hrs>