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 <[email protected]> wrote:
Am 27.07.2016 um 12:31 schrieb Julian Elischer <[email protected]>:
On 27/07/2016 9:36 PM, Dr. Rolf Jansen wrote:
Am 26.07.2016 um 23:03 schrieb Julian Elischer <[email protected]>:
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
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[email protected]"
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[email protected]"
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[email protected]"
