Hi Darren,
Ok, I just sat down and tried to map out an ippool strategy to my
problem and have come up with a few follow on questions...
1) It seems from the man page example that grpmap may act
like either a second "head" statement or a substitute for a
head statement. Without more than a "fragment" of a complete
ipf.conf and ippool.conf, it's hard to tell...
from the man page...
ipf.conf: call now fr_srcgrpmap/1010 in all
pass in all group 1020
block in all group 1030
ippool.conf: group-map in role = ipf number = 1010
{ 1.1.1.1/32, group = 1020; 3.3.0.0/16, group = 1030; };
Does there also need to be statements - head 1020 and
head 1030 in the above ipf.conf? Or must there not be?
2) This starts to make ipf look programmable.
Is there a kernel function similar to fr_srcgrpmap
that instead maps to a pool?
For example I'd like to do something like:
ipf.conf: #figure out which pool the incoming packet belongs in
call now fr_poolmap/100 in all
# "result" is returned from fr_poolmap
# if the packet address is covered by the pool, block it
block in fast from pool/result to any
ippool.conf: group-map in role = ipf number = 100
{0.0.0.0/8, pool = 1000;
1.0.0.0/8, pool = 1001;
:
:
255.0.0.0/8, pool = 1255;};
table role = ipf type = tree number = 1000
{};
table role = ipf type = tree number = 1001
{1.168.1.0/24;};
:
:
table role = ipf type = tree number = 1255
{ 255.129.205.167/32; 255.129.211.125/32;
255.129.225.165/32; 255.129.248.128/26; };
3) Is my syntax for empty pools and multi-line input correct above?
4) I would take it that ippool records have considerably less
kernel memory overhead than filter rules?
What I'm kinda looking for is a universal and efficient way
to filter out random addresses/subnets from the entire ipv4 space.
I can perform pre-sorting to prevent the entire list from being
traversed for each input.
Thanks,
gene
