From owner-freebsd-ipfw@freebsd.org Mon Jul 25 17:02:01 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4AE85BA4CDB for ; Mon, 25 Jul 2016 17:02:01 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from smtp.rlwinm.de (smtp.rlwinm.de [IPv6:2a01:4f8:201:31ef::e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1183A166B for ; Mon, 25 Jul 2016 17:02:01 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from vader9.bultmann.eu (unknown [87.253.189.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.rlwinm.de (Postfix) with ESMTPSA id CDEFF79E2 for ; Mon, 25 Jul 2016 19:01:57 +0200 (CEST) Subject: Re: ipfw divert filter for IPv4 geo-blocking To: freebsd-ipfw@freebsd.org References: <61DFB3E2-6E34-4EEA-8AC6-70094CEACA72@cyclaero.com> From: Jan Bramkamp Message-ID: <9d0a3ad8-a66a-c527-3906-3290b8d58476@rlwinm.de> Date: Mon, 25 Jul 2016 19:01:57 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <61DFB3E2-6E34-4EEA-8AC6-70094CEACA72@cyclaero.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 17:02:01 -0000 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.