ipfw Table Organization

Tim Daneliuk tundra at tundraware.com
Thu Aug 26 21:12:05 UTC 2021


On 8/24/21 5:30 PM, Michael Sierchio wrote:
> On Tue, Aug 24, 2021 at 2:47 PM Tim Daneliuk via freebsd-questions <
> freebsd-questions at freebsd.org> wrote:
> 
>> Is there any particular advantage - performance or otherwise - to breaking
>> up
>> a large ipfw table into smaller tables?
>>
>> We have a few firewalls approaching 100,000 rules for blocking addresses
>> and CIDR blocks.
> 
> 
> Do you really mean 100,000 firewall rules?  100,000 CIDR blocks is not
> a problem.  You should probably consolidate CIDR blocks before adding them
> to a
> table, because it's a longest-prefix-match.
> 
> 
>> The IPS are read from separate text files in a loop
>> in the firewall init code, but are all written to a single table.
> 
> 
> I have a framework that collects IPs and CIDR blocks from various sources
> (for blocking).
> Two tables are used for this – so I can atomically replace the table
> contents via table swap.
> None of this is done in the firewall init code, it's all done via a
> cronjob.  I use the table arg to
> store an integer that says what the source was.  The firewall init script
> only gets invoked at
> startup, or when rules change.
> 
> This
>> is easy to maintain, but the concern is that we may be clobbering runtime
>> performance.
>>
> 
> Did you know you can add an entire file to a table, if the lines consist of
> 
> <CIDR> <Table arg>
> 
> ?
> 
> Empirically, this works for up to 8192 entries, so I split the file into
> files of that size,
> add them, then delete the splits.  My pcengines box has
> 
> CPU: AMD GX-412TC SOC                                (998.15-MHz K8-class
> CPU)
> 
> 
> *root at hearst:/usr/src 210#* ipfw table reject list | wc -l
> 
>    99787
> 
> Something with decent power could easily filter 250,000 CIDR blocks.

As I thought about this, it led to a followup question.  Imagine
I have populated a table and then run this command:

    ipfw add deny all from table\(10\) to any via em0


If I then later update the contents of table 10, will those changes go live
on the firewall, or is the binding of table content to firewall rules only
relevant at the time the "add deny" is invoked?

To be more specific, I want to be able to build the table from a set of
flat files that list all the naughty IPs and CIDR blocks at boot time.
But I'd like to add/delete from that list as the system is running without
having to reload the firewall every time.


tl;dr I don't understand ipfw table semantics very well ...


More information about the freebsd-questions mailing list