From owner-freebsd-ipfw@freebsd.org Tue Aug 2 13:14:51 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4CC5BACE2A for ; Tue, 2 Aug 2016 13:14:51 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (gtw.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (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 692191C82; Tue, 2 Aug 2016 13:14:51 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 31A4724475; Tue, 2 Aug 2016 15:14:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7reZPTiaeSE; Tue, 2 Aug 2016 15:14:46 +0200 (CEST) Received: from [192.168.101.139] (vpn.ecoracks.nl [176.74.240.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 674CD24474; Tue, 2 Aug 2016 15:14:46 +0200 (CEST) Subject: Re: ipfw divert filter for IPv4 geo-blocking To: Julian Elischer , "Dr. Rolf Jansen" , freebsd-ipfw@freebsd.org References: <61DFB3E2-6E34-4EEA-8AC6-70094CEACA72@cyclaero.com> <4D047727-F7D0-4BEE-BD42-2501F44C9550@obsigna.com> <9641D08A-0501-4AA2-9DF6-D5AFE6CB2975@obsigna.com> <4d76a492-17ae-cbff-f92f-5bbbb1339aad@freebsd.org> <677900fb-c717-743f-fcfe-86b603466e33@freebsd.org> <0D3C9016-7A4A-46BA-B35F-3844D07562A8@obsigna.com> <1E1DB7E0-D354-4D7A-B657-0ECF94C12CE0@obsigna.com> <50d405a4-3f8f-a706-9cac-d1162925e56a@freebsd.org> <9222BB10-C700-4DE7-83A3-BE7A38A11713@obsigna.com> <1B36CAD7-A139-436B-B7EC-0FFF232F9C6A@obsigna.com> From: Willem Jan Withagen Message-ID: <2e7d84c7-e962-e131-b788-81a6489b9f95@digiware.nl> Date: Tue, 2 Aug 2016 15:14:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 13:14:51 -0000 On 1-8-2016 07:22, Julian Elischer wrote: > On 30/07/2016 10:17 PM, Dr. Rolf Jansen wrote: >> >> I am still a little bit amazed how ipfw come to accept incorrect CIDR >> ranges and arbitrarily moves the start/end addresses in order to >> achieve CIDR conformity, and that without any further notice, and that >> given that ipfw can be considered as being quite relevant to system >> security. Or, may I assume that ipfw knows always better than the user >> what should be allowed or denied. Otherwise, perhaps I am the only one >> ever who input incorrect CIDR ranges for processing by ipfw. > it's not so amazing when you think about it. The code comes from the > routing table.. > > In this context a.b.c.d/N means "the range of addresses containing > a.b.c.d, masked to a length of N". there is no specification that > a.b.c.d is the first address of the range. I have relied upon this > behaviour many times. I happily agree with Julian.... Rarely have I given the exact address of a router and it's net much thought. And apply happily a.b.c.27/26 in ipfw, assuming that ipfw would figure out what the actual network part of the address was. --WjW