Date: Mon, 17 Jan 2011 15:59:42 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Hiroki Sato <hrs@freebsd.org> Cc: jamesbrandongooch@gmail.com, freebsd-ipfw@freebsd.org, emax@freebsd.org Subject: Re: Request for policy decision: kernel nat vs/and/or natd Message-ID: <20110117151457.P81591@sola.nimnet.asn.au> In-Reply-To: <20110116132702.A62193@sola.nimnet.asn.au> References: <AANLkTinXREwAvvSQDtA65je2OdWcDQ9qR8rCh3my_26A@mail.gmail.com> <20110108141111.A15397@sola.nimnet.asn.au> <20110108220300.Q15397@sola.nimnet.asn.au> <20110116.011206.258445491489571055.hrs@allbsd.org> <20110116132702.A62193@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1464532019-1295240382=:81591 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 16 Jan 2011, Ian Smith wrote: > On Sun, 16 Jan 2011, Hiroki Sato wrote: > > 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> /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 Addressed below. > > 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. > > Hello Hiroki, Sorry to follow-up my own post, but after more research: > I'm not sure why, with the use of firewall_coscripts, natd was made to > start AFTER ipfw rules are loaded but BEFORE enabling the firewall, so I > don't know whether there had been negative consequences of starting natd > first? Nor do I know of any other use of firewall_coscripts, so adding > emax@ to the (trimmed) cc list as the committer of that change. Given someone/s may be using firewall_coscripts, without confirmation to the contrary I'd be inclined to leave that mechanism alone, except the avoidance of prefixing natd to _coscripts when firewall_nat is enabled. [..] > Because rc.d/natd has KEYWORD nostart, I gathered that it won't run on > startup, and by NOT prefixing it to _coscripts when firewall_nat is also > enabled, as in this patch, it won't be invoked by ipfw either. However > it could still be run manually, so really should have an explicit test > to NOT start /sbin/natd whenever firewall_nat="YES", assuming policy #1. > > And if rc.d/natd has such an explicit test for ! firewall_nat_enabled, > then it wouldn't matter when or how rc.d/natd was invoked? I'm not sure > how one should cleanly abandon an rc.d script without starting/stopping > anything though?, or I'd offer such a patch now. Ok, after studying rc.subr(8) and examining lots of rc.d scripts, the attached rc.d_natd.patch should deal with that gracefully, also warning the user that natd will not be started because firewall_nat is enabled. > If rc.d/natd can really _always_ be invoked safely before starting ipfw, > then the REQUIRE method should be fine - as long as rc.d/natd quits if > $firewall_nat is enabled - but I'm not sure how that may work especially > if the interface concerned relies on DHCP (ie -dynamic) and/or if the > interface hasn't an address yet, as CAN happen with ppp or (here) mpd? I still feel a bit uneasy about also altering the start/stop ordering when the main reason anyone wanted to start natd first was to ensure that ipdivert was loaded before encountering divert rules, now dealt with by ipfw_prestart. > Any more thoughts on start/stop ordering or interdependent conditions? cheers, Ian --0-1464532019-1295240382=:81591 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=rc.d_natd.patch Content-Transfer-Encoding: BASE64 Content-ID: <20110117155942.V81591@sola.nimnet.asn.au> Content-Description: Content-Disposition: attachment; filename=rc.d_natd.patch LS0tIG5hdGQuMS41LjEwLjEJVGh1IERlYyAyMyAxNjoyMDowOCAyMDEwDQor KysgbmF0ZAlNb24gSmFuIDE3IDE0OjUwOjEwIDIwMTENCkBAIC0xOCw2ICsx OCwxMSBAQA0KIA0KIG5hdGRfcHJlY21kKCkNCiB7DQorCWlmIGNoZWNreWVz bm8gZmlyZXdhbGxfbmF0X2VuYWJsZTsgdGhlbg0KKwkJd2FybiAibm90IHN0 YXJ0ZWQ6IGZpcmV3YWxsX25hdCBpcyBlbmFibGVkIg0KKwkJcmV0dXJuIDEN CisJZmkNCisNCiAJaWYgWyAtbiAiJHtuYXRkX2ludGVyZmFjZX0iIF07IHRo ZW4NCiAJCWRoY3BfbGlzdD0iYGxpc3RfbmV0X2ludGVyZmFjZXMgZGhjcGAi DQogCQlmb3IgaWZuIGluICR7ZGhjcF9saXN0fTsgZG8NCg== --0-1464532019-1295240382=:81591--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110117151457.P81591>