> Am 25.07.2016 um 12:47 schrieb Michael Sierchio <ku...@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 <cr...@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
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Reply via email to