Date: Mon, 25 Jul 2016 19:01:57 +0200 From: Jan Bramkamp <crest@rlwinm.de> To: freebsd-ipfw@freebsd.org Subject: Re: ipfw divert filter for IPv4 geo-blocking Message-ID: <9d0a3ad8-a66a-c527-3906-3290b8d58476@rlwinm.de> In-Reply-To: <61DFB3E2-6E34-4EEA-8AC6-70094CEACA72@cyclaero.com> References: <61DFB3E2-6E34-4EEA-8AC6-70094CEACA72@cyclaero.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 25/07/16 16:28, Dr. Rolf Jansen wrote: > I have written a ipfw divert filter daemon for IPv4 geo-blocking. It is working flawlessly on two server installations since a week. > > Anyway, I am still in doubt whether I do the blocking in the correct way. Once the filter receives a packet from the respective divert socket it looks up the country code of the source IP in the IP-Ranges database, and if the country code shall be allowed then it returns the unaltered packet via said socket, otherwise, the filter does no further processing, so the packet is effectively gone, lost, dropped, discarded, or whatever would be the correct terminology. Is this the really the correct way of denying a packet, or is it necessary to inform ipfw somehow about the circumstances, so it can run a proper dropping procedure? > > I uploaded the filter + accompanying tools to GitHub > > https://github.com/cyclaero/ipdb > > Many thnaks for any advices in advance. I would use a set of IPFW tables with skipto/call tablearg rules instead. Use the daemon to maintain the IPFW tables. I assume your database is a list of of (CIDR, country code) pairs. In that case the daemon config should probably map from sets of country codes to table values e.g. table 1 { DE, NL } -> 10000, { US, UK } -> 10100 table 2 { CN, KO, TR } -> 20000 Next the daemon would calculate the minimal set of table entries to match these policies exactly and patch the kernel table contents if the database changes. This design avoids the userspace<->kernel copies without losing flexibility.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9d0a3ad8-a66a-c527-3906-3290b8d58476>