From owner-freebsd-questions@freebsd.org Tue Feb 18 13:27:20 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D877B239134 for ; Tue, 18 Feb 2020 13:27:20 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48MM8l1grmz4Xkl for ; Tue, 18 Feb 2020 13:27:19 +0000 (UTC) (envelope-from roberthuff@rcn.com) DKIM-Signature: v=1; a=rsa-sha1; d=rcn.com; s=20180516; c=relaxed/simple; q=dns/txt; i=@rcn.com; t=1582032438; h=From:Subject:Date:To:MIME-Version:Content-Type; bh=EBkb5TQBgtK5/ndf4tj8pGXHpVA=; b=QedL047AREFTFoCYV0u6ObGTF0i9uq3Bh/i8k4K/qnsOowsDT07eRBgfbwKf97u3 12Yv4ZY5DisznsueNe8IcwmeXNSd8xVwzOk3V6StJKjj+ESwC/Fy1kRciVZxAT54 3PJD3CeqoNQnUBV63o7s4pNS9FB5sVZLX2+hQ2YGDa5+gw0a2tYTKyIUbdepOcAj sy4OAJaVTfUD/jSU+k0iXDzPfoIIiHFZ32XbhGQY0ItYt6Jgnua6YBYDYHMUfsHY bcvoiMD3mFjO/8Iuz9l2cyOFB0ofN9JX2xvUD5IVXGDGWKXaB03i91/qAXlI9gGY NaqK+ZSgUHLYj5zcqGNeYQ==; X_CMAE_Category: , , X-CNFS-Analysis: v=2.3 cv=bugy+3Si c=1 sm=1 tr=0 a=9TgA2UwI6Wy+6BV4wQM/cQ==:117 a=9TgA2UwI6Wy+6BV4wQM/cQ==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=KGjhK52YXX0A:10 a=kj9zAlcOel0A:10 a=XRQyMpdBKAEA:10 a=l697ptgUJYAA:10 a=48faUk6PgeAA:10 a=cl4OvlJKoLT-LbJWh84A:9 a=uJqDaDxzHuFOSMNw:21 a=5N4oX0JsD_lUJjDJ:21 a=CjuIK1q_8ugA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: cm9iZXJ0aHVmZkByY24uY29t Received: from [209.6.230.48] ([209.6.230.48:12105] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=AES256-GCM-SHA384) id E8/69-56402-536EB4E5; Tue, 18 Feb 2020 08:27:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24139.58932.915276.752500@jerusalem.litteratus.org> Date: Tue, 18 Feb 2020 08:27:16 -0500 From: Robert Huff To: Andreas X Cc: =?UTF-8?Q?Trond_Endrest=C3=B8l?= , Tim Daneliuk , FreeBSD Mailing List Subject: Re: Blacklist IP file for IPFW? In-Reply-To: References: <9585fce4-b48d-a210-d62f-a2100c0cf929@tundraware.com> X-Mailer: VM 8.2.0b under 26.3 (amd64-portbld-freebsd13.0) X-Rspamd-Queue-Id: 48MM8l1grmz4Xkl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=rcn.com header.s=20180516 header.b=QedL047A; dmarc=pass (policy=none) header.from=rcn.com; spf=pass (mx1.freebsd.org: domain of roberthuff@rcn.com designates 69.168.97.78 as permitted sender) smtp.mailfrom=roberthuff@rcn.com X-Spamd-Result: default: False [-4.59 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[rcn.com:s=20180516]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:69.168.97.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-1.49)[ip: (-9.27), ipnet: 69.168.97.0/24(1.02), asn: 36271(0.87), country: US(-0.05)]; DWL_DNSWL_LOW(-1.00)[rcn.com.dwl.dnswl.org : 127.0.5.1]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[rcn.com:+]; DMARC_POLICY_ALLOW(-0.50)[rcn.com,none]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_IN_DNSWL_LOW(-0.10)[78.97.168.69.list.dnswl.org : 127.0.5.1]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36271, ipnet:69.168.97.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 13:27:20 -0000 Andreas X writes: > Question is: If I don't add the rule number 00350 to that command, > that rule gets located to 65000s, and ipfw doesn't block the IPs in > table, at all. I wanted to ask why such react, shouldn't IPFW still > do the job (deny) even if the rule number belongs to last ones? I am not an IPFW expert ... but: It is my understanding IPFW stops processing a packet after the first rule that matches that packet. Am I wrong? If not, this suggests somewhere between rule 351 and rule 650000(-ish) is a rule that matches the packet and keeps it from getting processed by anything lower in the list. Would you be willing to publish your entire IPFW ruleset? Respectfully, Robert Huff