From owner-freebsd-arch@FreeBSD.ORG Sat Nov 1 05:16:11 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EDC0B1CB; Sat, 1 Nov 2014 05:16:11 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 44F411D6; Sat, 1 Nov 2014 05:16:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id sA15G85D081579; Sat, 1 Nov 2014 16:16:08 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 1 Nov 2014 16:16:07 +1100 (EST) From: Ian Smith To: Freddie Cash Subject: Re: any reason not to enable IPDIVERT for ipfw module? In-Reply-To: Message-ID: <20141101144834.N52402@sola.nimnet.asn.au> References: <20141031191212.GO8852@funkthat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net , freebsd-ipfw@freebsd.org, FreeBSD Arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 05:16:12 -0000 On Fri, 31 Oct 2014 18:28:28 -0700, Freddie Cash wrote: > On Oct 31, 2014 12:12 PM, "John-Mark Gurney" wrote: > > > > Can any one think of a good reason not to enable IPDIVERT sockets in > > the ipfw module? Yes, two. Nowadays people are just as or perhaps more likely to use in-kernel NAT, loading ipfw_nat.ko instead of ipdivert.ko, and there's no good reason to add extra code to ipfw.ko unless it's going to be used. See libalias(3) /MODULAR ARCHITECTURE Similaly there'd be no reason to include dummynet code unless using it. > > And possibly enabling default to accept? That way you don't have to > > go to the console when you load the ipfw module because you forgot to > > auto add the accept all rule? :) That'd reverse some 15+ years of security policy, of having the firewall closed until you've loaded your ruleset, to cater to forgetfulness? :) > You can change the default rule to accept via loader.conf and it will be > set when the module is loaded. > > net.inet.IP.fw.default_to_accept or something Luke that. Yes, net.inet.ip.fw.default_to_accept=1 is a loader tunable, and can be set before ipfw is loaded, unlike the net.inet.ip.fw sysctls which don't exist until ipfw is loaded. Or it can be set to 0 to reverse policy if kernel has been built with 'options IPFIREWALL_DEFAULT_TO_ACCEPT'. Normally /etc/rc.d/ipfw takes care of loading ipfw_nat or ipdivert (or both if you wanted to use both natd(8) and ipfw_nat for some reason?) and/or dummynet, according to the rc.conf variables. I've added freebsd-ipfw@ to ccs, just because it seems relevant .. cheers, Ian > > something like: > > ==== //depot/projects/opencrypto/sys/modules/ipfw/Makefile#3 - > /home/jmg/freebsd.p4/opencrypto/sys/modules/ipfw/Makefile ==== > > --- /tmp/tmp.15774.16 2014-10-31 12:11:56.000000000 -0700 > > +++ /home/jmg/freebsd.p4/opencrypto/sys/modules/ipfw/Makefile > 2014-10-31 12:11:54.000000000 -0700 > > @@ -16,7 +16,10 @@ > > #CFLAGS+= -DIPFIREWALL_VERBOSE_LIMIT=100 > > # > > #If you want it to pass all packets by default > > -#CFLAGS+= -DIPFIREWALL_DEFAULT_TO_ACCEPT > > +CFLAGS+= -DIPFIREWALL_DEFAULT_TO_ACCEPT > > +# > > +#If you want divert sockets > > +CFLAGS+= -DIPDIVERT > > # > > > > .include > > > > -- > > John-Mark Gurney Voice: +1 415 225 5579 > > > > "All that I will do, has been done, All that I have, has not."