Re: IPFilter 4.1: questions

In some email I received from Guido van Rooij, sie wrote:
[...]
> - IP-Filter framework in place for handling multiple different
> types of packet matching for firewalling.
> What do you mean with that?

Well, for example, now there are standard ipf rules, ones that use bpf
and ones that are (only) a function call. The rule structure is now
in two parts - the rule "infrastructure" and the packet matching bit.

> - Can convert IPv4 ipf rules into C code and either:
> * load them as an LKM o;
> * compile them statically into the kernel (where possible.)
> Do you have measurements.guestimates on the performance gain?

I did some quite a while ago and as you might expect, it depends on the
number of rules but the gain is quite significant.

> - NAT/ipf rules can refer to each other via a tag, creating an implied
> join that forms part of the packet matching.
> How does this work? Can you give an example?
> I do see "tag" for ip_nat, and "match_tag" and "set_tag" in ipf, but
> don't understand what it means.

It's meant to work something like this:

map ppp0 ... tag john
rdr ppp0 ... tag fred
pass in on ppp0 ... match-tag(nat fred)
pass out on ppp0 ... set-tag(nat john)

> - Extra packet attributes available for filter rules:
> * source address/routing interface mismatch;
> How do you specify this? ("bad-src"? is so -> what is "bad" )

Yes.
"bad" is the packet headers don't make sense. For example, TCP header
with all flags set or problems with IPv6 extension headers, etc.

> * multicast (3);
> Is this "multicast"
> * broadcast (2,3);
> I take it this is "bcast"?

Yes.

> What is "mbast"? is it broadcast or multicast?

Either.

> * state lookup partially failed;
> How do you specify this? And what exactly does it mean?

> * out of the TCP window for a state connection;
> Is this "oow" ?
> * NAT lookup partially failed.
> is this "bad-nat" ?

Yes to the above.

> What is "nat"?

Successfully NAT'd packets.

> - PPS (packets per second) matching available for ipf rules.
> This is "pps" ?

Yes.

> - Rule collections (cf FreeBSD numbering) supported for ipf rules.
> What do you mean with that?

You can do:
100 pass ...
100 blcok ...
200 pass ...

> Stateful Inspection:
> - Can insist that all TCP data arrives in order.
> This is specified with "keep state (strict)" right?
> - Can insist that all fragments pass through in order.
> This is specified with "keep frag (strict)" right?
> - The number of states created per-rule can be set where the total
> across all rules may exceed the maximum allowed.
> may exceed -> may not exceed, I take it?
> This is specified with "keep state (limit 10)" right?
> - Can elect not to automatically match ICMP error packets.
> This is specified with "keep state (noicmperr)" right?
> - TCP sequence number rewriting supported.
> This is specified with "keep state (newisn)" right?

Yes to the above.

> And combining these one can have:
> keep state (newisn, limit 100, strict)

That is the idea.

Darren