From owner-freebsd-ipfw@freebsd.org Fri Aug 5 12:10: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 DF004BB034B for ; Fri, 5 Aug 2016 12:10:29 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7FB691190 for ; Fri, 5 Aug 2016 12:10:29 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1470399027; l=4270; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=5NVqRtQ9SP5bG+5CflfKiea6cwWLUbxKN/aiMj2yd14=; b=uxB0fj6BPhp6sEePzczWGJ6DJaqHDc0O/Vxg7wpj2UWz6s4AlOEtITi8Ot5AZJavheB of3QVPeny10RgyedQZmoPVwEKeSzrcS25WOIdq9IqDF4MclLnfYKWne/UwEuUqUms2i65 pnOkY6reNejTrwl6vaU3ikZ5w3qlynfEAtU= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhToX1IWHkW4X7v2ImaU2B+3KSGnPFnK/TBWBCBcA X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bfb6bf8a.virtua.com.br [191.182.191.138]) by smtp.strato.de (RZmta 38.13 DYNA|AUTH) with ESMTPSA id Y09437s75CAQsSP (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Fri, 5 Aug 2016 14:10:26 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id E9955229861E for ; Fri, 5 Aug 2016 09:10:23 -0300 (BRT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: your thoughts on a particualar ipfw action. From: "Dr. Rolf Jansen" In-Reply-To: <7486c7ce-49db-b6b9-a6bb-13f04b4ce6d6@freebsd.org> Date: Fri, 5 Aug 2016 09:10:23 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160805024301.H56585@sola.nimnet.asn.au> <7486c7ce-49db-b6b9-a6bb-13f04b4ce6d6@freebsd.org> To: freebsd-ipfw@freebsd.org X-Mailer: Apple Mail (2.3124) 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: Fri, 05 Aug 2016 12:10:30 -0000 > Am 05.08.2016 um 02:44 schrieb Julian Elischer : > On 5/08/2016 2:22 AM, Dr. Rolf Jansen wrote: >> I am completely free of passions on this CC encoding thingy. I won't = use this feature anyway. Please, may I suggest that the experts of the = ipfw community come to an agreement, and I then I will change the = implementation accordingly. >>=20 >> Another possibility could be to attach the desired rule numbers = directly to the country codes in the argument of the -t option, How = about: >>=20 >> geoip -t AU=3D50000:RU=3D50010:US=3D50020:BR=3D50030 >>=20 >> The present behaviour would be kept without attached numbers. Please = let me know your choices. Furthermore, if the new ipfw allows for more = sophisticated table construction directives, that could be beneficial = for country code based table processing, please advice. >=20 > I can hear the exasperation in your writing :-) Not exactly 'exasperation'. Moving targets are always kind of unpleasant = - at least for me, perhaps I am not a sufficiently patient hunter :-) > I've lost track.. > Was the present behaviour just a single value? or a generated number = with -x offset? (not sure if you actually added that or just described = it). I meant, geoip would continue allowing a -t option argument without = numbers, for example -t AU:RU:US:BR, and in that case it would continue = with its present behaviour (mutually exclusive either -v XOR -x): -v # default 0 -x # in val =3D (C1-60)*1000 + C2*10 + offset The -v and -x options as above are already on GitHub, the x-formula can = be changed quickly.=20 > your "US=3D50020" idea is nice but a lot of work I think for you. Not that much work. I like this one as well, because this is the most = explicit way, that I can imagine, of associating a rule/action number = with a country code. I figure, that any kind of x-formula let people shoot themselves in the = foot at one day or the other. Imagine you set up your sophisticated rule = set in 2016 and in 2017 a colleague is asked by the boss to add another = country code. The trouble may start by she/he forgets to add an action = rule for the implicitly generated table argument, and it does not end = with a possible violation of the implicitly reserved rule number range. > I guess you would do it with script > geoip -t US=3D${LINE_US} |ipfw -q /dev/stdin > ipfw add ${LINE_US} drop all tcp from any to any 80 > ipfw add $((${LINE_US} + 1)) skipto ${FINISH_UP} Yes, why not? The nice thing of the "CC=3Dnnnnn:..." feature is, that it = is already useful as is, and that it is open for any further = sophistication with shell script magics. =20 > probably in a shell function > it would also allow you to put 'action numbers' rather than line = numbers as it doesn't interpret the values, just passes them through. >=20 > On the other hand the same thing can be achieved by embedding geoip in = a loop in a script. > I think we should just let you get on with your life and be happy with = what you have given us. mapping a set of country codes to a number. I = can always make more complicated setups using that and 15 minutes of = shell script. Yes, for us this is not a big deal. However, once this stuff is in the = ports, I have to take into account the work of answering questions from = the non-enlightened folks, on how to achieve the mapping between rule = numbers and country codes. Perhaps, it is less hassle to simply add the = "CC=3Dnnnnn:..." feature and move on. BTW: In the course of preparing the packet for the ports, I am working now on = a man file for the geoip db utilities (geoip, ipdb and ipdb-update.sh). = I want to put it to section 1 - General Commands, OK? Shall I remove the geod ipfw divert filter daemon from the distribution = for the ports? My initial incentive was Geo-blocking. However, I learned from your VPN = usage example (in your other message), that these utilities may quite = well serve for other objectives. Now, I am looking for a package title = that does suggest a wider range of applications. How about: "Utilities for IP based Geo-blocking/routing with IPFW" Best regards Rolf