Re: IPFW: more "orthogonal? state operations, push into 11?
Hello Julian, Thursday, August 4, 2016, 6:42:45 AM, you wrote: > A combination is less useful for me as you need to do: I'm against this too, as I really love orthogonality, as everybody know already, and your example is good example why. > 20 skipto 400 tcp from table(2) to me setup record-state > 21 skipto 400 tcp from table(2) to me setup > to make the entire session do the same thing. Sometimes it could be 20 skipto 400 tcp from table(2) to me setup record-state 21 check-state But only sometimes. -- Best regards, Levmailto:l...@freebsd.org pgpgq3uD3IS2C.pgp Description: PGP signature
Re: IPFW: more "orthogonal? state operations, push into 11?
On 04.08.16 06:42, Julian Elischer wrote: > so it's a combination of #1 and #2 in my list. I think I originally > thought of having just #1. > > A combination is less useful for me as you need to do: > > 20 skipto 400 tcp from table(2) to me setup record-state > 21 skipto 400 tcp from table(2) to me setup > to make the entire session do the same thing. So, in your example what wrong with just using keep-state? "record-state without immediate action" == "keep-state without implicit check-state" needed to solve issues with NAT or something similar, that was described by Lev. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: IPFW: more "orthogonal? state operations, push into 11?
On 04.08.16 06:58, Julian Elischer wrote: > o while thinking about states etc, it occured to me, what does THIS do > on subsequent packets in the session? > > > 10 skipto tablearg tcp from table(3) to me keep-state I think it will not work like you expected when you have created this rule :) -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: IPFW: more "orthogonal? state operations, push into 11?
On 4/08/2016 6:50 PM, Andrey V. Elsukov wrote: On 04.08.16 06:42, Julian Elischer wrote: so it's a combination of #1 and #2 in my list. I think I originally thought of having just #1. A combination is less useful for me as you need to do: 20 skipto 400 tcp from table(2) to me setup record-state 21 skipto 400 tcp from table(2) to me setup to make the entire session do the same thing. So, in your example what wrong with just using keep-state? "record-state without immediate action" == "keep-state without implicit check-state" needed to solve issues with NAT or something similar, that was described by Lev. because keep-state is a check-state for ALL packets going past, regardless of whether they match the pattern. at least that's what I have observed. ___ 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?
On 4/08/2016 6:27 PM, Lev Serebryakov wrote: Hello Julian, Thursday, August 4, 2016, 6:42:45 AM, you wrote: A combination is less useful for me as you need to do: I'm against this too, as I really love orthogonality, as everybody know already, and your example is good example why. 20 skipto 400 tcp from table(2) to me setup record-state 21 skipto 400 tcp from table(2) to me setup to make the entire session do the same thing. Sometimes it could be 20 skipto 400 tcp from table(2) to me setup record-state 21 check-state But only sometimes. exactly.. I don't want OTHER packets coming past here to hit a check-state yet.. I still have unfinished business with them. ___ 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?
On 4/08/2016 7:20 PM, Andrey V. Elsukov wrote: On 04.08.16 06:58, Julian Elischer wrote: o while thinking about states etc, it occured to me, what does THIS do on subsequent packets in the session? 10 skipto tablearg tcp from table(3) to me keep-state I think it will not work like you expected when you have created this rule :) yes that's what I was thinking.. I'm guessing that the table is not evaluated due to the dynamic match and thus the skipto fails, either doing nothing, or dropping the packet (not sure which) ___ 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?
On 04/08/16 18:12, Julian Elischer wrote: On 4/08/2016 6:50 PM, Andrey V. Elsukov wrote: On 04.08.16 06:42, Julian Elischer wrote: so it's a combination of #1 and #2 in my list. I think I originally thought of having just #1. A combination is less useful for me as you need to do: 20 skipto 400 tcp from table(2) to me setup record-state 21 skipto 400 tcp from table(2) to me setup to make the entire session do the same thing. So, in your example what wrong with just using keep-state? "record-state without immediate action" == "keep-state without implicit check-state" needed to solve issues with NAT or something similar, that was described by Lev. because keep-state is a check-state for ALL packets going past, regardless of whether they match the pattern. at least that's what I have observed. According to the documentation and my experience it is. As a workaround i use skipto $stateful + record-state. That way each stateful match continues processing at $stateful. Whilte it works it's hard to understand when combined with in-kernel NAT, because you end up with asymmetric paths through the ruleset for incoming and outgoing packets. ___ 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: your thoughts on a particualar ipfw action.
On Wed, 3 Aug 2016 18:53:38 -0300, Dr. Rolf Jansen wrote: > > Am 03.08.2016 um 11:13 schrieb Julian Elischer : > > On 2/08/2016 8:50 PM, Dr. Rolf Jansen wrote: >>> Am 02.08.2016 um 05:08 schrieb Julian Elischer : 'scuse savage reformatting, but I had to wrap it to read it .. and pine has completely mangled the quoting levels too, dunno why. >>> looking for thoughts from people who know the new IPFW features well.. That's not me, but I'm having fun reading 11.0-RELEASE ipfw(8) .. >>> A recent addition to our armory is the geoip program that, given an >>> address can tell you what country it is in and given a country code, >>> can give an ipfw table that describes all the ip addresses in that >>> country. >>> SO I was thinking how to use this, and the obvious way would be to >>> have a set of rules for each country, and use the "skipto tablearg" >>> facility to skip to the right rules for each country. But the >>> trouble is that a tablearg skipto is very inefficient. It's also a >>> hard thing to set up with a set of rules for each country (how many >>> countries are there in the internet allocation system?). Julian, have you looked into Andrey's LINEAR_SKIPTO ? How does it work? Are there any disadvantages? And if not, why isn't it the default? :) Also, There's a particularly useful example in new ipfw(8), showing how to set and use multiple tablearg values - the example uses skipto,fib with a setfib tablearg followed by a skipto tablearg both from the same table entry, and you can use, among others - some fully documented, some yet to catch up - dscp values (0..63) setting or testing, and notably tags 1..65534, set or test, which goes some way towards 'variables' you were hoping for, no? :) Also some netgraph stuff I won't understand .. >> As of today a total of 236 country codes are in use for IPv4 delegations. If this helps for anything, a command line switch to the geoip tool could be added for letting it output the country code (as the hex encoded CC taken as a plain decimal integer) as the value for the given table entry. In the moment you can give one value for all entries generated by geoip, with this switch set, the output of geoip could look like: >> $ geoip -t "DE:BR:US" -x >> ... >> table 0 add 93.157.48.0/21 4445 >> table 0 add 93.158.236.0/22 4252 >> table 0 add 93.159.96.0/19 4445 >> table 0 add 93.159.248.0/21 4445 >> table 0 add 93.180.72.0/21 4445 >> table 0 add 93.180.152.0/21 4445 >> table 0 add 93.181.0.0/18 4445 >> table 0 add 93.183.0.0/18 5553 >> ... >> >> Given that ... >> 0x4445 = 'DE' >> 0x4252 = 'BR' >> 0x5553 = 'US' > > well it would have to be the decimal value so DE would be 6869, as > while 4445 works 444F is a problem :-) RJ> Yes, you're right, I was taken away by the wave of enthusiasm, RJ> before thinking about the subject up to the end. > 0x444F would work but we waste even more address space. You'd have to multiply the numbers by some scaler, because adjacent numbers would not be enough for one rule to do something and another rule to skip on to somewhere else. (well, you could have multiple rules at the same number but that has its limitations. > The idea would certainly work. it would mean setting aside all the rules between 6565 and 9090 however. > A more compact encoding could be something like > ((name[0]-'A') * 32)+(name[1]-'A')) multiplied by some 'step' (maybe > 10 by default) and offset by a given offset. > so AF (Afghanistan) would be the first 0*32+5 * 10 would give an > offset of 50.. plus a user supplied offset turns it into say, 15050.. RJ> I understand the reasons, however, any complicated encoding will defeat the idea of the value can be sort of numeric mnemonic for the country code ÿÿ well, so it is. I elaborated on your idea and came-up with the following formula: val = (C1-60)*1000 + C2*10 + offset. The offset can be given as the parameter to the -x flag. $ geoip -t "DE:BR:US" -4 -x 3 ... table 0 add 93.157.48.0/21 38690 table 0 add 93.158.236.0/22 36820 table 0 add 93.159.96.0/19 38690 table 0 add 93.159.248.0/21 38690 table 0 add 93.180.72.0/21 38690 table 0 add 93.180.152.0/21 38690 table 0 add 93.181.0.0/18 38690 table 0 add 93.183.0.0/18 55830 ... The limits (without offset) are: AA = 5650 -- actually AD = 5680 ZZ = 30900 RJ> With this formula, the offset must be less than 34735. Although, this wastes a considerable amount of rule number space, the advantage is that the numbers are still accessible by mental arithmetic, and the other constraint of having a step > 1 is fulfilled as well. Anyway, this one is not graved in stone, we can agree on another one. Sorry, but that encoding takes up way too much (perhaps precious) rule space for one function, and I really can't see any mnemonic value in those numbers anyway; let's let the computers do the counting .. I'd go a but further than Julian here. Given the alpha country codes can only be AA .. ZZ, then using the same nota
Re: your thoughts on a particualar ipfw action.
<<< No Message Collected >>> ___ 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: your thoughts on a particualar ipfw action.
On Fri, 5 Aug 2016 01:38:45 +1000, Ian Smith wrote: > <<< No Message Collected >>> Yeah, sorry about that .. this got stuck in mailq somehow in 'locked' EHLO state .. never seen that before in many years; had to kill and resend it from sent-mail as a fwd, losing 'References:'. Weird. Ian ___ 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?
On Fri, 5 Aug 2016 00:12:37 +0800, Julian Elischer wrote: > On 4/08/2016 6:50 PM, Andrey V. Elsukov wrote: > > On 04.08.16 06:42, Julian Elischer wrote: > > > so it's a combination of #1 and #2 in my list. I think I originally > > > thought of having just #1. > > > > > > A combination is less useful for me as you need to do: > > > > > > 20 skipto 400 tcp from table(2) to me setup record-state > > > 21 skipto 400 tcp from table(2) to me setup > > > to make the entire session do the same thing. > > So, in your example what wrong with just using keep-state? > > "record-state without immediate action" == "keep-state without implicit > > check-state" needed to solve issues with NAT or something similar, that > > was described by Lev. > > > because keep-state is a check-state for ALL packets going past, regardless of > whether they match the pattern. > > at least that's what I have observed. Except now(?) with named states/flows/whatever, isn't it the case that check-state [flowname] only affects packets with same state/flowname? So you can clearly separate, say, packets on different interfaces, packets coming or going on any interface, and such? If I'm understanding that right - quite possibly not! - then only those packets will match, and others with other names (including 'default') won't match states with that name. I'm not sure I'm expressing this at all well, because I'm only just starting to get any sort of grip, but I'm liking the idea and wondering if it's sufficient for starters. To me, orthogonality implies the least number of commands/instructions that will accomplish the desired functionality. First, let's find out what can and cannot be accomplished with named states/flows .. I'm yet to understand what record-state-without-action can accomplish apart from that .. it could work only for the first packet I suppose, since once state is established, further packets will match and follow state, no? Again, I find concrete examples - like the use of valtype skipto,fib mentioned above - really helpful, essential really, for bears of such little brain as I .. cheers, Ian ___ 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: your thoughts on a particualar ipfw action.
> Am 04.08.2016 um 13:44 schrieb Ian Smith : >> On Wed, 3 Aug 2016 18:53:38 -0300, Dr. Rolf Jansen wrote: Am 03.08.2016 um 11:13 schrieb Julian Elischer : > > 'scuse savage reformatting, but I had to wrap it to read it .. and pine > has completely mangled the quoting levels too, dunno why. > > looking for thoughts from people who know the new IPFW features well.. > > That's not me, but I'm having fun reading 11.0-RELEASE ipfw(8) .. > > A recent addition to our armory is the geoip program that, given an > address can tell you what country it is in and given a country code, > can give an ipfw table that describes all the ip addresses in that > country. > > SO I was thinking how to use this, and the obvious way would be to > have a set of rules for each country, and use the "skipto tablearg" > facility to skip to the right rules for each country. But the > trouble is that a tablearg skipto is very inefficient. It's also a > hard thing to set up with a set of rules for each country (how many > countries are there in the internet allocation system?). > > Julian, have you looked into Andrey's LINEAR_SKIPTO ? How does it work? > Are there any disadvantages? And if not, why isn't it the default? :) > > Also, There's a particularly useful example in new ipfw(8), showing how > to set and use multiple tablearg values - the example uses skipto,fib > with a setfib tablearg followed by a skipto tablearg both from the same > table entry, and you can use, among others - some fully documented, some > yet to catch up - dscp values (0..63) setting or testing, and notably > tags 1..65534, set or test, which goes some way towards 'variables' you > were hoping for, no? :) Also some netgraph stuff I won't understand .. > As of today a total of 236 country codes are in use for IPv4 delegations. If this helps for anything, a command line switch to the geoip tool could be added for letting it output the country code (as the hex encoded CC taken as a plain decimal integer) as the value for the given table entry. In the moment you can give one value for all entries generated by geoip, with this switch set, the output of geoip could look like: $ geoip -t "DE:BR:US" -x ... table 0 add 93.157.48.0/21 4445 table 0 add 93.158.236.0/22 4252 table 0 add 93.159.96.0/19 4445 table 0 add 93.159.248.0/21 4445 table 0 add 93.180.72.0/21 4445 table 0 add 93.180.152.0/21 4445 table 0 add 93.181.0.0/18 4445 table 0 add 93.183.0.0/18 5553 ... Given that ... 0x4445 = 'DE' 0x4252 = 'BR' 0x5553 = 'US' >>> >>> well it would have to be the decimal value so DE would be 6869, as >>> while 4445 works 444F is a problem :-) >> >> Yes, you're right, I was taken away by the wave of enthusiasm, >> before thinking about the subject up to the end. >> >>> 0x444F would work but we waste even more address space. You'd have to >>> multiply the numbers by some scaler, because adjacent numbers would not >>> be enough for one rule to do something and another rule to skip on to >>> somewhere else. (well, you could have multiple rules at the same number >>> but that has its limitations. > The idea would certainly work. it would >>> mean setting aside all the rules between 6565 and 9090 however. > A more >>> compact encoding could be something like >>> >>> ((name[0]-'A') * 32)+(name[1]-'A')) multiplied by some 'step' (maybe >>> 10 by default) and offset by a given offset. >>> >>> so AF (Afghanistan) would be the first 0*32+5 * 10 would give an >>> offset of 50.. plus a user supplied offset turns it into say, 15050.. >> >> I understand the reasons, however, any complicated encoding will >> defeat the idea of the value can be sort of numeric mnemonic for the >> country code ÿÿ well, so it is. I elaborated on your idea and came-up >> with the following formula: val = (C1-60)*1000 + C2*10 + offset. The >> offset can be given as the parameter to the -x flag. >> >> $ geoip -t "DE:BR:US" -4 -x 3 >> ... >> table 0 add 93.157.48.0/21 38690 >> table 0 add 93.158.236.0/22 36820 >> table 0 add 93.159.96.0/19 38690 >> table 0 add 93.159.248.0/21 38690 >> table 0 add 93.180.72.0/21 38690 >> table 0 add 93.180.152.0/21 38690 >> table 0 add 93.181.0.0/18 38690 >> table 0 add 93.183.0.0/18 55830 >> ... >> >> The limits (without offset) are: >> AA = 5650 -- actually AD = 5680 >> ZZ = 30900 >> >> With this formula, the offset must be less than 34735. Although, >> this wastes a considerable amount of rule number space, the advantage is >> that the numbers are still accessible by mental arithmetic, and the >> other constraint of having a step > 1 is fulfilled as well. Anyway, this >> one is not graved in stone, we can agree on another one. > > Sorry, but that encoding takes up way too much (perhaps precious) rule > space for one function, and I really can
Re: your thoughts on a particualar ipfw action.
On 5/08/2016 12:44 AM, Ian Smith wrote: On Wed, 3 Aug 2016 18:53:38 -0300, Dr. Rolf Jansen wrote: > > Am 03.08.2016 um 11:13 schrieb Julian Elischer : On 2/08/2016 8:50 PM, Dr. Rolf Jansen wrote: Am 02.08.2016 um 05:08 schrieb Julian Elischer : 'scuse savage reformatting, but I had to wrap it to read it .. and pine has completely mangled the quoting levels too, dunno why. looking for thoughts from people who know the new IPFW features well.. That's not me, but I'm having fun reading 11.0-RELEASE ipfw(8) .. A recent addition to our armory is the geoip program that, given an address can tell you what country it is in and given a country code, can give an ipfw table that describes all the ip addresses in that country. SO I was thinking how to use this, and the obvious way would be to have a set of rules for each country, and use the "skipto tablearg" facility to skip to the right rules for each country. But the trouble is that a tablearg skipto is very inefficient. It's also a hard thing to set up with a set of rules for each country (how many countries are there in the internet allocation system?). Julian, have you looked into Andrey's LINEAR_SKIPTO ? How does it work? Are there any disadvantages? And if not, why isn't it the default? :) no, until he mentioned i I was unaware of it.. I will be looking at it as soon as 1 have time. Also, There's a particularly useful example in new ipfw(8), showing how to set and use multiple tablearg values - the example uses skipto,fib with a setfib tablearg followed by a skipto tablearg both from the same table entry, and you can use, among others - some fully documented, some yet to catch up - dscp values (0..63) setting or testing, and notably tags 1..65534, set or test, which goes some way towards 'variables' you were hoping for, no? :) Also some netgraph stuff I won't understand .. tags "almost" do variables but they stick on the packet after it leaves ipfw and may cause misinterpretation if the packet enters ipfw a second time. It's a question of scope. As of today a total of 236 country codes are in use for IPv4 delegations. If this helps for anything, a command line switch to the geoip tool could be added for letting it output the country code (as the hex encoded CC taken as a plain decimal integer) as the value for the given table entry. In the moment you can give one value for all entries generated by geoip, with this switch set, the output of geoip could look like: $ geoip -t "DE:BR:US" -x ... table 0 add 93.157.48.0/21 4445 table 0 add 93.158.236.0/22 4252 table 0 add 93.159.96.0/19 4445 table 0 add 93.159.248.0/21 4445 table 0 add 93.180.72.0/21 4445 table 0 add 93.180.152.0/21 4445 table 0 add 93.181.0.0/18 4445 table 0 add 93.183.0.0/18 5553 ... Given that ... 0x4445 = 'DE' 0x4252 = 'BR' 0x5553 = 'US' well it would have to be the decimal value so DE would be 6869, as while 4445 works 444F is a problem :-) RJ> Yes, you're right, I was taken away by the wave of enthusiasm, RJ> before thinking about the subject up to the end. 0x444F would work but we waste even more address space. You'd have to multiply the numbers by some scaler, because adjacent numbers would not be enough for one rule to do something and another rule to skip on to somewhere else. (well, you could have multiple rules at the same number but that has its limitations. > The idea would certainly work. it would mean setting aside all the rules between 6565 and 9090 however. > A more compact encoding could be something like ((name[0]-'A') * 32)+(name[1]-'A')) multiplied by some 'step' (maybe 10 by default) and offset by a given offset. so AF (Afghanistan) would be the first 0*32+5 * 10 would give an offset of 50.. plus a user supplied offset turns it into say, 15050.. RJ> I understand the reasons, however, any complicated encoding will defeat the idea of the value can be sort of numeric mnemonic for the country code ÿÿ well, so it is. I elaborated on your idea and came-up with the following formula: val = (C1-60)*1000 + C2*10 + offset. The offset can be given as the parameter to the -x flag. $ geoip -t "DE:BR:US" -4 -x 3 ... table 0 add 93.157.48.0/21 38690 table 0 add 93.158.236.0/22 36820 table 0 add 93.159.96.0/19 38690 table 0 add 93.159.248.0/21 38690 table 0 add 93.180.72.0/21 38690 table 0 add 93.180.152.0/21 38690 table 0 add 93.181.0.0/18 38690 table 0 add 93.183.0.0/18 55830 ... The limits (without offset) are: AA = 5650 -- actually AD = 5680 ZZ = 30900 RJ> With this formula, the offset must be less than 34735. Although, this wastes a considerable amount of rule number space, the advantage is that the numbers are still accessible by mental arithmetic, and the other constraint of having a step > 1 is fulfilled as well. Anyway, this one is not graved in stone, we can agree on another one. Sorry, but that encoding takes up way too much (perhaps precious) rule space for one function, and I really can't see any mnemonic value in those numbers an
Re: your thoughts on a particualar ipfw action.
Wouldn't it make sense to use the ISO Numeric Code / UN M49 Numerical Code? On Thu, Aug 4, 2016 at 9:00 PM, Julian Elischer wrote: > On 5/08/2016 12:44 AM, Ian Smith wrote: > >> On Wed, 3 Aug 2016 18:53:38 -0300, Dr. Rolf Jansen wrote: >> > > Am 03.08.2016 um 11:13 schrieb Julian Elischer > >: >> >>> On 2/08/2016 8:50 PM, Dr. Rolf Jansen wrote: >>> Am 02.08.2016 um 05:08 schrieb Julian Elischer : > 'scuse savage reformatting, but I had to wrap it to read it .. and pine >> has completely mangled the quoting levels too, dunno why. >> >> looking for thoughts from people who know the new IPFW features well.. > That's not me, but I'm having fun reading 11.0-RELEASE ipfw(8) .. >> >> A recent addition to our armory is the geoip program that, given an > address can tell you what country it is in and given a country code, > can give an ipfw table that describes all the ip addresses in that > country. > SO I was thinking how to use this, and the obvious way would be to > have a set of rules for each country, and use the "skipto tablearg" > facility to skip to the right rules for each country. But the > trouble is that a tablearg skipto is very inefficient. It's also a > hard thing to set up with a set of rules for each country (how many > countries are there in the internet allocation system?). > Julian, have you looked into Andrey's LINEAR_SKIPTO ? How does it work? >> Are there any disadvantages? And if not, why isn't it the default? :) >> > no, until he mentioned i I was unaware of it.. > I will be looking at it as soon as 1 have time. > >> >> Also, There's a particularly useful example in new ipfw(8), showing how >> to set and use multiple tablearg values - the example uses skipto,fib >> with a setfib tablearg followed by a skipto tablearg both from the same >> table entry, and you can use, among others - some fully documented, some >> yet to catch up - dscp values (0..63) setting or testing, and notably >> tags 1..65534, set or test, which goes some way towards 'variables' you >> were hoping for, no? :) Also some netgraph stuff I won't understand .. >> > tags "almost" do variables but they stick on the packet after it leaves > ipfw and may cause misinterpretation if the packet enters ipfw a second > time. It's a question of scope. > > > >> As of today a total of 236 country codes are in use for IPv4 >>> delegations. If this helps for anything, a command line switch to the >> geoip tool could be added for letting it output the country code (as the >> hex encoded CC taken as a plain decimal integer) as the value for the >> given table entry. In the moment you can give one value for all entries >> generated by geoip, with this switch set, the output of geoip could look >> like: >> >> $ geoip -t "DE:BR:US" -x ... table 0 add 93.157.48.0/21 4445 table 0 add 93.158.236.0/22 4252 table 0 add 93.159.96.0/19 4445 table 0 add 93.159.248.0/21 4445 table 0 add 93.180.72.0/21 4445 table 0 add 93.180.152.0/21 4445 table 0 add 93.181.0.0/18 4445 table 0 add 93.183.0.0/18 5553 ... Given that ... 0x4445 = 'DE' 0x4252 = 'BR' 0x5553 = 'US' >>> well it would have to be the decimal value so DE would be 6869, as >>> while 4445 works 444F is a problem :-) >>> >> RJ> Yes, you're right, I was taken away by the wave of enthusiasm, >> RJ> before thinking about the subject up to the end. >> >> 0x444F would work but we waste even more address space. You'd have to >>> >> multiply the numbers by some scaler, because adjacent numbers would not >> be enough for one rule to do something and another rule to skip on to >> somewhere else. (well, you could have multiple rules at the same number >> but that has its limitations. > The idea would certainly work. it would >> mean setting aside all the rules between 6565 and 9090 however. > A more >> compact encoding could be something like >> >> ((name[0]-'A') * 32)+(name[1]-'A')) multiplied by some 'step' (maybe >>> 10 by default) and offset by a given offset. >>> so AF (Afghanistan) would be the first 0*32+5 * 10 would give an >>> offset of 50.. plus a user supplied offset turns it into say, 15050.. >>> >> RJ> I understand the reasons, however, any complicated encoding will >> defeat the idea of the value can be sort of numeric mnemonic for the >> country code ÿÿ well, so it is. I elaborated on your idea and came-up >> with the following formula: val = (C1-60)*1000 + C2*10 + offset. The >> offset can be given as the parameter to the -x flag. >> >> $ geoip -t "DE:BR:US" -4 -x 3 >> ... >> table 0 add 93.157.48.0/21 38690 >> table 0 add 93.158.236.0/22 36820 >> table 0 add 93.159.96.0/19 38690 >> table 0 add 93.159.248.0/21 38690 >> table 0 add 93.180.72.0/21 38690 >> table 0 add 93.180.152.0/21 38690 >> table 0 add 93.181.0.0/18 38690 >> table 0 add 93.183.0.0/18 55830 >> ... >> >> The limits (without offset) are: >> AA = 5650 -- actua
Re: IPFW: more "orthogonal? state operations, push into 11?
On 5/08/2016 2:14 AM, Ian Smith wrote: On Fri, 5 Aug 2016 00:12:37 +0800, Julian Elischer wrote: > On 4/08/2016 6:50 PM, Andrey V. Elsukov wrote: > > On 04.08.16 06:42, Julian Elischer wrote: > > > so it's a combination of #1 and #2 in my list. I think I originally > > > thought of having just #1. > > > > > > A combination is less useful for me as you need to do: > > > > > > 20 skipto 400 tcp from table(2) to me setup record-state > > > 21 skipto 400 tcp from table(2) to me setup > > > to make the entire session do the same thing. > > So, in your example what wrong with just using keep-state? > > "record-state without immediate action" == "keep-state without implicit > > check-state" needed to solve issues with NAT or something similar, that > > was described by Lev. > > > because keep-state is a check-state for ALL packets going past, regardless of > whether they match the pattern. > > at least that's what I have observed. Except now(?) with named states/flows/whatever, isn't it the case that check-state [flowname] only affects packets with same state/flowname? So you can clearly separate, say, packets on different interfaces, packets coming or going on any interface, and such? If I'm understanding that right - quite possibly not! - then only those packets will match, and others with other names (including 'default') won't match states with that name. I'm not sure I'm expressing this at all well, because I'm only just starting to get any sort of grip, but I'm liking the idea and wondering if it's sufficient for starters. we not quite.. Only the given state table will be looked at, but all packets will still be matched with it. To me, orthogonality implies the least number of commands/instructions that will accomplish the desired functionality. First, let's find out what can and cannot be accomplished with named states/flows .. I'm yet to understand what record-state-without-action can accomplish apart from that .. it could work only for the first packet I suppose, since once state is established, further packets will match and follow state, no? Again, I find concrete examples - like the use of valtype skipto,fib mentioned above - really helpful, essential really, for bears of such little brain as I .. ok, so sometimes I like to do some processing on a packet (e.g. divert it somewhere for munging) after I've set up a state for it. so I don't want to necessarily Act on the state immediately. but the packet may get changed in the munging, so I need to set the state before hand., or I can't match it. here's a real example that I couldn't do because I couldn't store a state without actually doing it. I wanted all packets from a process on the local machine (identified because it has a unique group, used for just this purpose) to be forwarded to a particular other machine for "vetting', however the machine I am doing this has outgoing NAT using a modified natd that also does some added "stuff". After the NAT I can no longer recognise the packets that came from that process as they moved out of the kernel to userland and back, yet I still need these ackets to go through the natd. So I need to identify them first, before the nat in order to set a state entry for them. Since they are local packets NAT will not have changed their addresses, so AFTER the NAT I could have done the associated check-state which triggers the stored action (forwarding to another location). 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. Having said that, "store without do" is the least important of the features. Store (do or not) without a prior checkstate is more important to me. state name are a wonderful addition that I have yet to use in all my scripts I just haven't had time yet. cheers, Ian ___ 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: your thoughts on a particualar ipfw action.
On 5/08/2016 12:15 PM, Michael Sierchio wrote: Wouldn't it make sense to use the ISO Numeric Code / UN M49 Numerical Code? actually it doesn't make sense. the source of data doesn't have that information in it so it would require a whole layer of mapping, including downloads. and it would have to cope with unexpected ambiguities and mismatches. ___ 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: your thoughts on a particualar ipfw action.
On Fri, 5 Aug 2016 13:22:50 +0800, Julian Elischer wrote: > On 5/08/2016 12:15 PM, Michael Sierchio wrote: > > Wouldn't it make sense to use the ISO Numeric Code / UN M49 Numerical Code? > actually it doesn't make sense. the source of data doesn't have that > information in it so it would require a whole layer of mapping, > including downloads. and it would have to cope with unexpected > ambiguities and mismatches. Yeah, no .. to address this point first, I misunderstood mention of it to indicate that data was also available in what geoip is using. Given that it's not, agreed it'd be way too much hassle to synchronise .. cheers, Ian ___ 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: your thoughts on a particualar ipfw action.
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 :-)
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).
your "US=50020" idea is nice but a lot of work I think for you.
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}
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.
___
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: your thoughts on a particualar ipfw action.
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.
Which has a munimum value of 0 (AA) and maximum of 25 * 26 + 25 = 675,
so at a spacing of 10 (less would do, but room for at least a couple in
between for patching) is a much smaller range of 0 .. 6750, plus offset,
potentially less if step size were also optional.
I will be ready to change the encoding scheme to anything on which the
community will have been agreed upon.
I think you very first idea is best
geoip -t AU:US:DE -n ${GEO_TABLE} -v ${ALLOW_VALUE} |ipfw -q /dev/stdin
we can embed that into scripts any way we want.
let's call this "done", drop it into a port and get onto more
productive things..
thanks for all the work and I already have a use for this in my home
network..
My "home" network spreads over 2 continents with VPNs etc and I
sometimes want to make sure that reaching certain sites only happens
from the exit point near the destination, due to geo blocking. I think
using geo-ip to sidestep geo blocking will be a perfect use.
___
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"
