From owner-freebsd-ipfw@freebsd.org Tue Jul 26 16:26:51 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 52657BA498D for ; Tue, 26 Jul 2016 16:26:51 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 30FA71315 for ; Tue, 26 Jul 2016 16:26:50 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-233-115.lns20.per1.internode.on.net [121.45.233.115]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u6QGQhnL067602 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 26 Jul 2016 09:26:48 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: ipfw divert filter for IPv4 geo-blocking To: freebsd-ipfw@freebsd.org References: <61DFB3E2-6E34-4EEA-8AC6-70094CEACA72@cyclaero.com> <9d0a3ad8-a66a-c527-3906-3290b8d58476@rlwinm.de> From: Julian Elischer Message-ID: Date: Wed, 27 Jul 2016 00:26:37 +0800 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: <9d0a3ad8-a66a-c527-3906-3290b8d58476@rlwinm.de> 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: Tue, 26 Jul 2016 16:26:51 -0000 On 26/07/2016 1:01 AM, Jan Bramkamp wrote: > > > 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 why multiple tables? if you load the table at once you can assign a country code as the tablearg for every run of addresses. all in one table. > > 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. > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >