ipfw divert filter for IPv4 geo-blocking

[Dr. Rolf Jansen]

> Am 25.07.2016 um 12:47 schrieb Michael Sierchio <kudzu at tenebras.com>:
> 
> Writing a divert daemon is a praiseworthy project, but I think you could do
> this without sending packets to user land.
> 
> You could use tables - …


> Am 25.07.2016 um 14:01 schrieb Jan Bramkamp <crest at rlwinm.de>:
> 
> I would use a set of IPFW tables with skipto/call tablearg rules instead …

Michael and Jan, many thanks for your suggestions.

As everybody knows, 'Many roads lead to Rome.', and I am already there. I don't feel alike going all the way back only for the sake of trying out other routes.

Once a week, the IP ranges are compiled from original sources into a binary sorted table, containing as of today 83162 consolidated range/cc pairs. On starting-up, the divert daemon reads the binary file in one block and stores the ranges into a totally balanced binary search tree. Looking-up a country code for a given IPv4 address in the BST takes on average 20 nanoseconds on an AWS-EC2 micro instance. I don't know the overhead of diverting, though. I guess this may be one or two orders of magnitudes higher. Even though, I won't see any performance issues.

Independent from the actual usage case (geo-blocking), let's talk about divert filtering in general. The original question which is still unanswered can be generalized to, whether "dropping/denying" a package simply means 'forget about it' or whether the divert filter is required to do something more involved, e.g. communicate the situation somehow to ipfw.

Best regards

Rolf