From owner-freebsd-net@freebsd.org Tue Jun 18 19:26:02 2019 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C789E15C65EB; Tue, 18 Jun 2019 19:26:02 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 038FB8AD77; Tue, 18 Jun 2019 19:26:01 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id A307E4E669; Tue, 18 Jun 2019 12:26:00 -0700 (PDT) From: "Ronald F. Guilmette" cc: FreeBSD Net , Mailinglists FreeBSD Subject: Re: Eliminating IPv6 (?) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23657.1560885960.1@segfault.tristatelogic.com> Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jun 2019 12:26:00 -0700 Message-ID: <23658.1560885960@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 038FB8AD77 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [-3.03 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.987,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; IP_SCORE(-2.73)[ip: (-7.17), ipnet: 69.62.128.0/17(-3.59), asn: 14051(-2.83), country: US(-0.06)]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mx1.tristatelogic.com]; RCPT_COUNT_TWO(0.00)[2]; MISSING_TO(2.00)[]; NEURAL_HAM_SHORT(-0.11)[-0.113,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; RCVD_COUNT_TWO(0.00)[2]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 19:26:03 -0000 In message Andreas Nilsson wrote: >I have no ipv6 rules in ipfw when configuring rc.conf as: > >firewall_enable=3D"YES" >firewall_script=3D"/etc/ipfw.rules". I don't know what to say, other than that this was not my experience. When I first noiced that /etc/rc.firewall was injecting rules into ipfw, prior to my own set of explicitly specified rules, I went into the script and edited it to try to cause it to stop doing at least some of this (unwanted) behavior. For example, please note the lines in the following function which have been commented out: setup_loopback() { ############ # Only in rare cases do you want to change these rules # ${fwcmd} add 100 pass all from any to any via lo0 # ${fwcmd} add 200 deny all from any to 127.0.0.0/8 # ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any # if [ $ipv6_available -eq 0 ]; then # ${fwcmd} add 400 deny all from any to ::1 # ${fwcmd} add 500 deny all from ::1 to any # fi } Commenting out the lines shown above (as commented out) *did* make a difference. To be crystal clear, I found that even when I was explicitly requesting that my own custom rule set be used, as per the instructions in the Handbook (and as I have been doing already for lo these many years) I found that "ipfw -a list" was showing that I was getting several additional rules (which I personally DID NOT specify in my rules file) and these additional rules were appearing in the output of "ipfw -a list" = AHEAD OF my own explicitly specified rules. I traced this down and quickly saw that these additional rules could only have come from the (now commented out) lines shown above. After I had commented those lines out of the /etc/rc.firewall script an rebooted the system, the rules in question no longer were visible in the output of "ipfw -a list". I also made one other local change to the /etc/rc.firewall script, which i= s illustrated by the following (locally revised) code snippet: afexists inet6 #ipv6_available=3D$? # disable creation of any/all IPv6 rules ipv6_available=3D1 I can't remember anymore now if this had the desired effect or not. It certainly didn't seem to hurt anything, at least from my personal perspective. (But please remember, I am striving to -not- use IPv6 at all.) Even with these multiple changes, the /etc/rc.firewall script is *still* injecting its own "pass all from any to any via lo0" rule ahead of my own explicitly specified rules. (See the setup_loopback() function above.= ) I do not have any objection to that perfectly sensible rule, so I did not comment out the specific line of /etc/rc.firewall where that is added, ahe= ad of all user-specified rules. But the point remains that /etc/rc.firewall *is* injecting its own rules, even when the user has followed the Handbook= 's prescription for how to take complete control of his/her own IPFW rule writing. Regards, rfg