ipfw divert filter for IPv4 geo-blocking

Fri Jul 29 04:57:00 UTC 2016

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 <http://www.subnet-calculator.com/cidr.php> helps :)
>
> On Thu, Jul 28, 2016 at 7:21 PM, Dr. Rolf Jansen <rj at obsigna.com> wrote:
>
>>> Am 27.07.2016 um 12:31 schrieb Julian Elischer <julian at freebsd.org>:
>>> On 27/07/2016 9:36 PM, Dr. Rolf Jansen wrote:
>>>>> Am 26.07.2016 um 23:03 schrieb Julian Elischer <julian at freebsd.org>:
>>>>> 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 at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
>> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-ipfw at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe at freebsd.org"
>
>