From owner-freebsd-ipfw@freebsd.org Mon Jul 25 15:47:29 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 F31FBBA42ED for ; Mon, 25 Jul 2016 15:47:29 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C33171E7B for ; Mon, 25 Jul 2016 15:47:29 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: by mail-qt0-x236.google.com with SMTP id x25so99398623qtx.2 for ; Mon, 25 Jul 2016 08:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tenebras-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=XZg3LCLdBme7zbeiY/ZEQKpK+nwSmKNuo5LPOCe5/iw=; b=tz6de0MrvQ9KqUjGI5MoI+HOMLBJAAorsl/0zMtD7S763ikPO21fPz5qVkE69Z8Pbp IN2N0gfv6eNn9movMW6On1Np38yA8JXw85qvjxBaf46Ib0wADaEOK+9sDVxsqmaml2QX 0pWuyLbBcM8qq5z11Tmq5gr1iliQgvWurNt+idWok8HiCnK0fJj628EfwJ8KMGzaRNGx MSluIsfbwX62fEx20J2ObLMNlQyRZadiVhSUe8+p00WfT7rjX5p2r/BjhY8jz/rEqGhE c2j1+EePFHsAqpM1mEIOThKCylP5FbkYnj9jePEXjoc5I2Inlvpi4fSlawRaCgJWtLkL QJeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=XZg3LCLdBme7zbeiY/ZEQKpK+nwSmKNuo5LPOCe5/iw=; b=ijcaocoUPOZqGLyYj074PN6HQzUEF3h/8POoWKQQF14iTHfWVELgMu577KZ/7JZGtt qOPjkQnOIDk9iN/qQ5X/pB9dhjB0sLiU2QsOfX3uNGoYOVSIDPh7Ie7SOnOvm4U5pU75 LixaJey9HwqKMqvu1Tdu85KlOWXu9i9ODU4NgDLDHWmRDD1n9BDCk0Kd+SL2QZTHOY21 UN/wA9gQhPQRR7iaX/7VBvA7e9Ogxx8KNfaC9nao+Vpv/NN/fCcb2z4RMlqrro3+Km4e XpUZ2IBSraUYd8xcNAo5FQ7lNijean4AjotBcMP6wC46e+YmQGSWbnp0cmQtgWeKw5QH RrJQ== X-Gm-Message-State: AEkoouui1IYrDaMMP+whHt3PQOOsCz0JOG+h1FAuOu2Lt7idPD81VHXHN7KHGDqTSkuiRElNzA5Z0zGKKHik6lzE MIME-Version: 1.0 X-Received: by 10.237.37.99 with SMTP id w32mr29745862qtc.59.1469461648756; Mon, 25 Jul 2016 08:47:28 -0700 (PDT) Received: by 10.200.39.249 with HTTP; Mon, 25 Jul 2016 08:47:28 -0700 (PDT) Received: by 10.200.39.249 with HTTP; Mon, 25 Jul 2016 08:47:28 -0700 (PDT) In-Reply-To: <61DFB3E2-6E34-4EEA-8AC6-70094CEACA72@cyclaero.com> References: <61DFB3E2-6E34-4EEA-8AC6-70094CEACA72@cyclaero.com> Date: Mon, 25 Jul 2016 08:47:28 -0700 Message-ID: Subject: Re: ipfw divert filter for IPv4 geo-blocking From: Michael Sierchio To: "Dr. Rolf Jansen" Cc: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 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 15:47:30 -0000 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 - in fact, a single table of consolidated nets by country, in which the table entry is a CIDR block and the table arg is a country code - and you match on table arg. You could simply put nets you want to block in a table, and dispense with table args. That is how I do it. In order to do changes atomically, you need a pair of tables and a pair of rulesets, and you can swap rulesets when you have built the new table. On Jul 25, 2016 07:29, "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. > > 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" >