From owner-freebsd-ipfw@freebsd.org Fri Jul 29 04:57:00 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 6FB2FBA6F2B for ; Fri, 29 Jul 2016 04:57:00 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 43249100F for ; Fri, 29 Jul 2016 04:56:59 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-233-115.lns20.per1.internode.on.net [121.45.233.115]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u6T4ula8079317 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 28 Jul 2016 21:56:51 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: ipfw divert filter for IPv4 geo-blocking To: Lee Brown , freebsd-ipfw@freebsd.org, "Dr. Rolf Jansen" 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> From: Julian Elischer Message-ID: <089bea1b-dd31-aec1-c0e4-dba4ac6066aa@freebsd.org> Date: Fri, 29 Jul 2016 12:56:41 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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: Fri, 29 Jul 2016 04:57:00 -0000 On 29/07/2016 10:48 AM, Lee Brown wrote: > That makes sense to me. Your /20 range encompasses 201.222.16.0 - > 201.222.31.255. > If you want 201.222.20.0-201.222.31.255, you'll need 3 ranges: whether it makes sense depends on whether you add the other ranges as well with the default result. Your daemon has the entire set loaded so it can exclude other internal ranges, however it looks like you have only provided ipfw with partial information. you'd need to add: 201.222.20.0/20 1 201.222.16.0/22 0 or more correctly what Lee showed above either the imput data is incorrect, or your cidr aggregation code has a bug. because 201.222.20.0/20 (well more correctly "misleading") cidr description). It implies 201.222.16.0/20 because if you mask 201.222.20.0 with 255.255.240.0 (/20) that's what you get. observe: soekris# route add 201.222.20.0/20 127.0.0.1 add net 201.222.20.0: gateway 127.0.0.1 soekris# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.0.1 UGS 0 9082198 vr2 [...] 201.222.16.0/20 127.0.0.1 US 0 0 lo0 [...] to make this work correctly you'd either need lee's answer, or you need to give it more information: 201.222.16.0/20 {result for brazil} 201.222.16.0/22 {default result, to get subtracted from the above. your program give s the correct result because it has all the information, including the AR information but you didn't tell ipfw about that. I suggest you need either input data sanitization, or to fix our output code to give the correct subranges. becasue 201.222.16.0/20 is definately bad input to ipfw. > > 201.222.20.0/22 (201.222.20.0-201.222.23.255) > 201.222.24.0/22 (201.222.24.0-201.222.27.255) > 201.222.28.0/22 (201.222.28.0-201.222.31.255) > > this helps :) > > On Thu, Jul 28, 2016 at 7:21 PM, Dr. Rolf Jansen wrote: > >>> Am 27.07.2016 um 12:31 schrieb Julian Elischer : >>> On 27/07/2016 9:36 PM, Dr. Rolf Jansen wrote: >>>>> Am 26.07.2016 um 23:03 schrieb Julian Elischer : >>>>> On 27/07/2016 3:06 AM, Dr. Rolf Jansen wrote: >>>>>> There is another tool called geoip , that I uploaded to GitHub, and >> that I use for looking up country codes by IP addresses on the command line. >>>>>> https://github.com/cyclaero/ipdb/blob/master/geoip.c >>>>>> >>>>>> This one could easily be extended to produce sorted IP ranges per CC >> that could be fed into tables of ipfw. I am thinking of adding a command >> line option for specifying CC's for which the IP ranges should be exported, >> something like: >>>>>> geoip -e DE:BR:US:IT:FR:ES >>>>>> >>>>>> And this could print sorted IP-Ranges belonging to the listed >> countries. For this purpose, what would be the ideal format for directly >> feeding the produced output into ipfw tables? >>>>> The format for using tables directly is the same as that used for >> routing tables. >>>>> … >>>>> table 5 add 1.1.1.0/32 1000 >>>>> … >>>>> your application becomes an application for configuring the firewall. >>>>> (which you do by feeding commands down a pipe to ipfw, which is >> started as 'ipfw -q /dev/stdin') >>>> I finished adding a second usage form for the geoip tool, namely >> generation of ipfw table construction directives filtered by country codes. >>> wow, wonderful! >>> >>> with that tool, and ipfw tables we have a fully functional geo >> blocking/munging solution in about 4 lines of shell script. >> >> Unfortunately, I finally discovered that ipfw tables as they are, are >> unsuitable for the given purpose, because for some reason ipfw mangles >> about 20 % of the passed IP address/masklen pairs. >> >> For example: >> >> # ipfw table 1 add 201.222.20.0/20 >> # ipfw table 1 list >> --> 201.222.16.0/20 0 >> >> $ geoip 201.222.20.1 >> --> 201.222.20.1 in 201.222.20.0-201.222.31.255 in BR >> >> $ geoip 201.222.16.1 >> --> 201.222.16.1 in 201.222.16.0-201.222.19.255 in AR >> >> Effectively, I asked ipfw to add an IP-range of Brazil to table 1, but it >> actually added another one which belongs to Argentina. This doesn't make >> too much sense, does it? >> >> For the time being I switched my servers back to geo-blocking with the >> divert filter daemon. >> >> Best regards >> >> Rolf >> >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > >