ipfw divert filter for IPv4 geo-blocking

[Julian Elischer]

On 26/07/2016 1:41 AM, Dr. Rolf Jansen wrote:
>> 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.
and I personally am responsible for at least parts of several of them ;-)
(parts of ipdivert, netgraph, and various ipfw bits).


>
> 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.

yes the diversion to user space is not a fast operation. When we wrote 
it, fast was 10Mbits/sec.
The firewall tables use a radix tree (*) and might be slower than what 
you have, but possibly it might be made up for by not having to do the 
divert logic. it's not entorely clear from your description why you 
look up  a country rather than just a pass/block result, but maybe 
different sources can access different countries?.

I did similar once using ipfw tables but couldn't find a reliable 
source of data.

>
> 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.

there is no residual information about the packet in the kernel once 
it has been passed to the  user process.
so just "forgetting to hand it back" is sufficient to drop it.

>
> 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"
>
>