Re: your thoughts on a particualar ipfw action.

[Dr. Rolf Jansen]

> 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.
>> 
>> Another possibility could be to attach the desired rule numbers directly to 
>> the country codes in the argument of the -t option, How about:
>> 
>>   geoip -t AU=5:RU=50010:US=50020:BR=50030
>> 
>> 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.
> 
> 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 = (C1-60)*1000 + C2*10 + offset

The -v and -x options as above are already on GitHub, the x-formula can be 
changed quickly. 

> your "US=50020" 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=${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=n:..." feature is, that it is 
already useful as is, and that it is open for any further sophistication with 
shell script magics.  

> 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.
> 
> 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=n:..." 
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

___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: IPFW: more "orthogonal? state operations, push into 11?

[Jan Bramkamp]

On 05/08/16 06:36, Julian Elischer wrote:

I ended up having to do this via an ugly use of skiptos where packets
I wanted to forward, were identified early and then sent to a duplicate
set of
rules which also did the divert,  but then did the forward. I think
there were
about 25 rules duplicated.


You could deduplicate this with a call/return pair but good luck ever 
debugging it if something goes wrong because the call/return stack is 
tied to the mbuf "allowing" you to call during igress and return during 
egress for maximal confusion.

___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"