can ipfw check all permit rules without search termination?

[Lowell Gilbert]

s m <sam.gh1986 at gmail.com> writes:

> thanks for your answers. you know, i have different services and each one
> writes ipfw rules in different times. i want to aggregated all rules. i
> mean if two rules which are written by two different services, have overlap
> (for example rule number 222 permit packets with 192.168.5.5 src address
> while rule number 225 permit packets with 192.168.5.5 src address and set
> next-hop 192.168.10.2 for them), the rule which is more specified, match.

You want to use tables for these host-by-host rules. Otherwise managing
the data gets unwieldy.

> in my example, i want to rule number 222 match for packets.
> in the other words, ipfw uses "first match win" search method. can i change
> this method???

No. There are other firewalls that use other algorithms. The way to make
priority work in ipfw is to simply arrange your rules so that either the
one that takes priority gets checked *first*, or the other one gets
skipped.

In your example, you didn't show any reason why the next-hop rule came
after rather than before the accept rule. In my experience, the only
time it's difficult to arrange the priority is when the treatment of a
packet is *intended* to depend on more than one positive match; in such
cases, making the first match a "skipto" rule instead of "permit" has
always been enough to structure the logic as I needed.

The details depend on exactly what you want to do. If a given packet may
end up with multiple kinds of special treatment, you might be better
with a firewall that carries more state as the firewall rules are
traversed, like pf.

If the total number of ways packets can be treated is relatively small,
you should be able to do fine with ipfw by checking the outright rejects
first, the special treatments second, accepts third, and perhaps
defaulting to reject after that. If the packets run through NAT, things
get a little more complicated because you want to check source addresses
before NAT and destination addresses afterwards -- but the rc.firewall
that ships with FreeBSD demonstrates how to handle that.

As a final note, I suspect that the next-hop rule is inappropriate. If,
instead of setting the next-hop in the firewall, you just set a route in
the routing table for that host, would you get the behaviour you want?

Good luck.