From owner-freebsd-ipfw@freebsd.org Tue Jul 26 16:23:31 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 906FEBA4918 for ; Tue, 26 Jul 2016 16:23:31 +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 629AA1271 for ; Tue, 26 Jul 2016 16:23:31 +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 u6QGNC0W067590 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 26 Jul 2016 09:23:20 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: ipfw divert filter for IPv4 geo-blocking To: "Dr. Rolf Jansen" , freebsd-ipfw@freebsd.org References: <61DFB3E2-6E34-4EEA-8AC6-70094CEACA72@cyclaero.com> <4D047727-F7D0-4BEE-BD42-2501F44C9550@obsigna.com> Cc: Michael Sierchio , Jan Bramkamp From: Julian Elischer Message-ID: Date: Wed, 27 Jul 2016 00:23:06 +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: <4D047727-F7D0-4BEE-BD42-2501F44C9550@obsigna.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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:23:31 -0000 On 26/07/2016 1:41 AM, Dr. Rolf Jansen wrote: >> Am 25.07.2016 um 12:47 schrieb Michael Sierchio : >> >> 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 : >> >> 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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > >