From owner-freebsd-ipfw@FreeBSD.ORG Thu Dec 23 14:58:59 2010 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 1F869106566B for ; Thu, 23 Dec 2010 14:58:59 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 6BE818FC16 for ; Thu, 23 Dec 2010 14:58:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id oBNEwus4056588 for ; Fri, 24 Dec 2010 01:58:56 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 24 Dec 2010 01:58:55 +1100 (EST) From: Ian Smith To: freebsd-ipfw@freebsd.org Message-ID: <20101223233437.Q27345@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: 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: Thu, 23 Dec 2010 14:58:59 -0000 Folks, [ If someone implements an /etc/rc.d/ipfw reload command that reliably works over a remote session without any open firewall window, great, but I'd rather not discuss the related issues below in reponses to any PR ] In order to address issues (and PRs) introduced by and since adding kernel nat and more recently firewall_coscripts, before offering any code it's clearly necessary to determine policy for what we should do when both natd_enable and firewall_nat_enable are set in rc.conf. "Don't do that" is not a policy, people will and already are bumping into this, affecting startup scripts and nat[d] rules in rc.firewall. We could: 1) Preference kernel nat over natd when both are enabled. 2) Preference natd over kernel nat when both are enabled. 3) Load both, including both modules, and include both nat and divert rules in the firewall constructed by rc.firewall types and/or another script configured as firewall_type - as happens now with rc.firewall, except kernel nat rules may crash if ipfw_nat isn't loaded, as below. My vote, so it's out of the way, is for (1). We've already seen people enabling firewall_nat while still having natd enabled, and to me it seems clear that adding firewall_nat will be intended to supercede natd. I think this would require a new test in /etc/rc.d/natd as well, or perhaps just making the prefixing of natd to _coscripts conditional. Relatively recent ipfw_prestart (paste, tabs lost) has chosen (2): 1.17 mtm 23: ipfw_prestart() 24: { 25: if checkyesno dummynet_enable; then 26: required_modules="$required_modules dummynet" 27: fi 1.19 emax 28: 29: if checkyesno firewall_nat_enable; then 30: if ! checkyesno natd_enable; then 31: required_modules="$required_modules ipfw_nat" 32: fi 1.24 ! dougb 33: fi ie ipfw_nat module is only required when natd is NOT also enabled - but this won't affect anything with ipfw_nat in kernel, or loaded at boot. http://www.freebsd.org/cgi/query-pr.cgi?pr=153155 doesn't address the above quandary, but does provide what seems to be the necessary and correct fix for that and 2 other 2010 PRs, namely, again de-tabbed: --- rc.d/ipfw (revision 216439) +++ rc.d/ipfw (working copy) @@ -31,6 +31,10 @@ required_modules="$required_modules ipfw_nat" fi fi + + if checkyesno natd_enable; then + required_modules="$required_modules ipdivert" + fi } ipfw_start() which removes any temptation to suggest running /etc/rc.d/natd first. Then there's rc.firewall .. currently the NAT section (except for firewall_type="simple") will load both nat and divert rules, perhaps fortunately having the same rule number (again, pasted): case ${natd_enable} in [Yy][Ee][Ss]) if [ -n "${natd_interface}" ]; then ${fwcmd} add 50 divert natd ip4 from any to any via ${natd_interface} fi ;; esac case ${firewall_nat_enable} in [Yy][Ee][Ss]) if [ -n "${firewall_nat_interface}" ]; then if echo "${firewall_nat_interface}" | \ grep -q -E '^[0-9]+(\.[0-9]+){0,3}$'; then firewall_nat_flags="ip ${firewall_nat_interface} ${firewall_nat_flags}" else firewall_nat_flags="if ${firewall_nat_interface} ${firewall_nat_flags}" fi ${fwcmd} nat 123 config log ${firewall_nat_flags} ${fwcmd} add 50 nat 123 ip4 from any to any via ${firewall_nat_interface} fi ;; esac Garrett Cooper ran into this a while ago. We later figured that as the divert rule reenters the firewall at the next higher-numbered rule, not the next rule, then only natd would actually be invoked - but still it's not an ideal situation in the face of a possibly not uncommon config. Suggested patches (David Naylor's or mine) to add kernel nat support to 'simple' ruleset in http://www.freebsd.org/cgi/query-pr.cgi?pr=148144 would generate two different-numbered rules now if both were enabled, so this is another place where a clear decision on policy 1,2 or 3 above (or 4 if you've got a better idea :) would be really helpful. cheers, Ian PS I've got both 7.4-PRE and 8.2-PRE installed here, and apart from the IPv6 stuff, /etc/rc.d/{ipfw,natd} are in synch between both versions, and also with HEAD if I'm not mistaken. It's a bit harder to tell when http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.d/ipfw is out of date at least re what's in 7.4-PRE, ie rev 1.15.2.6 2010/08/17 21:28:40 jhb