Request for policy decision: kernel nat vs/and/or natd

[Ian Smith]

On Sun, 16 Jan 2011, Ian Smith wrote:
 > On Sun, 16 Jan 2011, Hiroki Sato wrote:
 >  > Ian Smith <smithi at nimnet.asn.au> wrote
 >  >   in <20110108220300.Q15397 at 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 at 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
-------------- next part --------------
--- natd.1.5.10.1	Thu Dec 23 16:20:08 2010
+++ natd	Mon Jan 17 14:50:10 2011
@@ -18,6 +18,11 @@
 
 natd_precmd()
 {
+	if checkyesno firewall_nat_enable; then
+		warn "not started: firewall_nat is enabled"
+		return 1
+	fi
+
 	if [ -n "${natd_interface}" ]; then
 		dhcp_list="`list_net_interfaces dhcp`"
 		for ifn in ${dhcp_list}; do